Az éves szerverdíj csak egy része egy mobilapp fenntartásának. Saját frissítési tapasztalatainkon és három tervezési példán mutatjuk meg, hogyan válaszd külön a működés, a technikai frissítések és az új funkciók költségét.
Elkészült az alkalmazás, megjelent az áruházakban, működik a szerver. Mennyibe kerül mindezt fenntartani a következő három évben?
Az éves tárhelyszámla még nem ad választ. Egy alkalmazásnál külön költség a háttérrendszer működtetése, a szükséges technikai frissítés és az új funkciók fejlesztése. Ráadásul ezek eltérő ütemben jelentkeznek: a szervert rendszeresen fizeted, egy nagyobb keretrendszer-frissítés viszont egyetlen időszakban hozhat jelentősebb kiadást.
A Petadevnél alapvetően projektalapon dolgozunk: felmérjük az elvégzendő feladatot és előre egyeztetett árat adunk rá. Nincs kötelező havi karbantartási díjunk. Az infrastruktúra díjai ettől függetlenül felmerülnek; külön szerződött 24/7 felügyelethez pedig havidíjas megállapodás tartozik.
Ebben a cikkben az indulás utáni költségeket vesszük végig. Az első verzió elkészítésének ársávjait a mobilalkalmazás-fejlesztési oldalunkon találod.
Röviden
- Három évre egy egyszerű appnál nettó 350-600 ezer Ft, egy összetettebbnél 2-5 millió Ft szerver- és frissítési kerettel érdemes számolni az alábbi tervezési feltételezések mellett.
- Egy kis terhelésű startup-MVP szervere a saját gyakorlatunkban évi nettó 50 000 Ft körül is fenntartható. Ez kizárólag a szerverköltség.
- Webshopos rendszereknél évi nettó 50 000-500 000 Ft közötti szerverdíjjal is találkozunk, a rendszer és a terhelés függvényében.
- Az elmúlt 1-2 évben legalább 30 keretrendszer-frissítésen dolgoztunk. Tapasztalataink szerint egy ilyen munka nettó 200 000 Ft-tól akár 4 millió Ft-ig terjedhet.
- A nagyobb forgalom infrastruktúra-bővítést és használatfüggő szolgáltatási díjakat hozhat.
- Az új funkciókra szánt keretet érdemes külön kezelni a meglévő működés fenntartásától.
Az összegek nettó, 2026. októberi tapasztalati számok; a hároméves példák tervezési forgatókönyvek.
Miből áll egy mobilapp fenntartási költsége?
A tervezéshez négy részre érdemes bontani a kiadásokat.
| Költségtípus | Mi tartozhat ide? | Mikor merül fel? |
|---|---|---|
| Rendszeres infrastruktúra és fiókok | Szerver, adatbázis, domain, levelezés, mentési tárhely, áruházi tagság | Havi vagy éves rendszerességgel |
| Használatfüggő szolgáltatások | SMS, térképes API, AI-használat, azonosítás, adatforgalom, fizetési díjak | A tényleges használattal |
| Technikai fenntartási munkák | Keretrendszer- és csomagfrissítés, kompatibilitási hibák javítása, infrastruktúra-költöztetés | Szükség szerint, külön feladatként |
| Termékfejlesztés | Új funkciók, új piac, új integráció, új üzleti folyamat | Üzleti döntés alapján |
Nem minden app használ minden felsorolt szolgáltatást. A költségtervbe a ténylegesen szükséges elemek kerüljenek és azt is rögzítsétek, hogy valamelyik díj már tartalmaz-e másik tételt.
Szerver, domain és levelezés
Egy kezdeti, alacsony forgalmú MVP-nél a szerver nem feltétlenül nagy kiadás. Saját projektjeinknél évi nettó 50 000 Ft körüli induló szerverköltséggel is dolgozunk. A domain, levelezés és más kapcsolódó szolgáltatások díját a konkrét csomag szerint kell mellé tenni.
Egy webshopos rendszer kiszolgálása szélesebb sávban mozoghat: nálunk évi nettó 50 000-500 000 Ft közötti költség is előfordul. A termékmennyiség mellett a forgalom, keresések, képek, háttérfeladatok és integrációk is számítanak.
Ha az app egy meglévő webshophoz kapcsolódik, először azt kell tisztázni, mennyi a mobilalkalmazás miatti többletköltség. A már fizetett webshopos szervert nem érdemes még egyszer teljes egészében az app költségeként elszámolni.
Apple- és Google-fejlesztői fiók
Az Apple Developer Program tagsági díja jelenleg évi 99 USD, illetve régiótól függően helyi pénznemben meghatározott összeg. Változatlan díjjal három tagsági év 297 USD.
A Google Play Console regisztrációja egyszeri 25 USD. Ha ezt az induláskor már kifizetted, nem jelent újabb éves fenntartási díjat.
Ezek fejlesztői fiókhoz kapcsolódó díjak, nem alkalmazásonkénti éves díjak. A tényleges forintos összeget az elszámolási pénznem, árfolyam és adózás is befolyásolhatja. A vásárlásokhoz kapcsolódó szolgáltatói díjakat és jutalékokat külön kell számolni.
Miért kell fizetni frissítésért, ha nem kérsz új funkciót?
Mert az alkalmazás környezete akkor is változik, ha a terméked funkciólistája ugyanaz marad.
Új Android- vagy iOS-verzió jelenik meg, módosulhat egy fizetési vagy térképes szolgáltatás, elavulhat egy használt csomag, illetve változhatnak az áruházi beküldés technikai feltételei.
A Google Play célzott API-szintre vonatkozó előírásai külön kezelik az új verziók beküldését és a meglévő appok elérhetőségét. Az Apple a feltöltött alkalmazásokhoz használt fejlesztőeszközökre és SDK-kra is meghatároz követelményeket. Az adott feltétel teljesítéséhez szükséges munkát a projekt állapota határozza meg.
Az áruházi SDK-követelmény és például egy Expo- vagy React Native-verzióváltás nem ugyanaz. A gyakorlatban azonban a szükséges platformfrissítés további csomagok, beállítások és kódrészek módosítását is magával hozhatja.
Mennyibe kerülhet egy nagyobb keretrendszer-frissítés?
Az elmúlt 1-2 évben legalább 30 ilyen frissítésen dolgoztunk. A tapasztalt ársáv nettó 200 000-4 000 000 Ft, de a sáv két vége nagyon különböző feladatot jelenthet.
Az árat többek között ez befolyásolja:
- milyen verzióról indul az alkalmazás;
- hány és milyen külső csomagot használ;
- kell-e valamelyik csomagot vagy saját megoldást lecserélni;
- milyen hibák jelennek meg a frissítés után;
- hány fontos felhasználói folyamatot kell újratesztelni;
- milyen kiadási és publikálási feladatok szükségesek.
A Trinity Guard egyik korábbi, Expo SDK 48-ról 52-re történő frissítésénél például a visszanavigáció hibái miatt a navigáció átdolgozására is szükség volt. A teljes folyamat körülbelül két hétig tartott a javításokkal, teszteléssel és publikálással együtt. Ez jól mutatja, miért nem becsülhető meg a munka pusztán a verziószám alapján.
Évente vagy kétévente érdemes frissíteni?
Nincs minden alkalmazásra érvényes, legolcsóbb ütemezés. A gyakorlatunkban körülbelül kétévente is felmerülhet nagyobb frissítés, de ez nem általános áruházi előírás.
Előfordulhat, hogy még nincs új beküldési határidő, egy újabb telefonon vagy operációs rendszeren azonban már hiba jelentkezik. Egy megszűnő integráció vagy biztonsági probléma szintén korábbi beavatkozást indokolhat.
A költségtervben ezért legyen keret technikai frissítésre, az időzítését pedig a tényleges követelmények és problémák alapján határozzátok meg.
Hároméves költségterv: három számpélda
Az alábbi példákban különböző működési helyzeteket számolunk végig. A szerverdíjak a megadott tapasztalati sávokon belüliek; a frissítési összegek a számítás kedvéért választott keretek, amelyeket egy valódi projektnél felmérés alapján kell meghatározni.
Mindhárom példa egy nagyobb frissítéssel számol a második évben. Ez tervezési feltételezés: egy konkrét appnál a beavatkozások száma és időzítése eltérhet.
| Tétel, nettó Ft | Kis terhelésű MVP | Egyenletes forgalmú webshopos rendszer | A második évtől külön AWS-környezetben működő app |
|---|---|---|---|
| 1. év szerverköltsége | 50 000 | 200 000 | 50 000 |
| 2. év szerverköltsége | 50 000 | 200 000 | 420 000 |
| 3. év szerverköltsége | 50 000 | 200 000 | 420 000 |
| Egy nagyobb frissítés tervezési kerete | 400 000 | 800 000 | 1 200 000 |
| Egyszeri AWS-költöztetés | 0 | 0 | 350 000 |
| A felsorolt tételek hároméves részösszege | 550 000 | 1 400 000 | 2 440 000 |
A részösszeghez még hozzáadandó: a szükséges domain és levelezés, áruházi tagság, használatfüggő szolgáltatások, a táblázatban nem szereplő technikai munkák, valamint az opcionálisan választott felügyelet. Az új funkciók fejlesztési kerete külön szerepeljen.
A számítás változatlan egységárakkal készült; nem tartalmaz három évre előre feltételezett áremelést vagy árfolyamváltozást.
Mit mutatnak ezek a példák?
A kis MVP-nél az éves 50 000 Ft szerverdíj három év alatt 150 000 Ft. A feltételezett 400 000 Ft-os frissítéssel együtt már 550 000 Ft a két költségcsoport összege. Vagyis az olcsó szerver mellett is érdemes külön tartalékot képezni a technikai munkára.
A webshopos példában az évi 200 000 Ft-os szerverköltség a rendszer feltételezett kiszolgálási díja. Ha a webshop ezt az app nélkül is fizetné, az appnak tulajdonítható többletköltséget külön kell meghatározni.
A harmadik példa a második év elejétől havi 35 000 Ft AWS-költséggel számol: két év alatt ez 840 000 Ft. Ehhez az első év 50 000 Ft-ja, a 350 000 Ft-os költöztetés és az 1,2 millió Ft-os frissítési keret adódik.
Egyetlen nagyobb frissítés ára jelentősen módosíthatja a végösszeget. Például ha az MVP-nél feltételezett 400 000 Ft helyett 800 000 Ft-os munka válik szükségessé, ugyanaz a részösszeg 950 000 Ft-ra nő. Ezt a bizonytalanságot egy olcsóbb szerver önmagában nem oldja meg.
Mekkora kerettel érdemes számolni három évre?
Egy nagyon egyszerű, kis terhelésű mobilappnál nettó 350-600 ezer forint körüli kerettel érdemes számolni három évre, ha a szerver mellett egy kisebb technikai frissítésre is szükség lesz. Egy összetettebb alkalmazásnál a szerver és a szükséges frissítések költsége nettó 2-5 millió forintot is elérhet, nagyobb terhelés vagy több jelentős frissítés esetén pedig ezt is meghaladhatja.
Az egyszerű appnál három év szervere 150 000 Ft; egy 200 000-400 000 Ft-os frissítéssel együtt ez 350 000-550 000 Ft. A 600 000 Ft-os felső tervezési keret némi tartalékot is hagy.
Ezek tervezési összegek a szerverre és a technikai frissítésekre. Az áruházi fiókok, a domain, a levelezés, az egyéb külső szolgáltatások és az új funkciók költségét külön kell hozzájuk számolni. A saját alkalmazásodhoz szükséges keretet a működés, a terhelés és a technikai állapot alapján érdemes meghatározni.
Mi történik, ha beindul az alkalmazás?
Növekvő terhelésnél szükség lehet külön felhős környezet kialakítására és költöztetésre. Az általunk végzett AWS-költöztetéseknél egyszeri nettó 200 000-500 000 Ft is lehet a tervezési kiindulópont, a rendszer és a költöztetés feladatai szerint.
Az ilyen projektjeinknél havi nettó 30 000-40 000 Ft körüli induló felhőköltséggel is számolunk. Ez az általunk használt konfigurációkra vonatkozó tapasztalat; nagyobb adatforgalom, több szolgáltatás és magasabb rendelkezésre állási igény mellett a díj ennek többszöröse lehet. Az AWS díjazása a választott erőforrásoktól és használattól függ.
A felhasználószám önmagában kevés a becsléshez. Ezer, havonta egyszer belépő felhasználó egészen más terhelést jelenthet, mint ezer, naponta képeket feltöltő és AI-funkciót használó ember.
Használatfüggő szolgáltatásoknál azt érdemes követni, hogy:
- hány fizetős API-hívás vagy művelet történik;
- mennyi adatot tárol és továbbít a rendszer;
- mennyibe kerül egy aktív felhasználó vagy tranzakció kiszolgálása;
- ehhez mekkora bevétel tartozik.
A növekedés akkor kedvező üzletileg, ha a bevétel a többletköltséget is fedezi. A fizetéshez kapcsolódó díjak megértéséhez a mobilappos fizetési megoldásokról szóló cikkünk ad további szempontokat.
A továbbfejlesztésre külön keret kell
Egy beinduló startupnál jellemzően megjelennek az új igények: másik fizetési mód, új szerepkör, több nyelv, új üzleti folyamat vagy külső integráció.
Tapasztalataink szerint egy aktívan fejlődő terméknél 1-3 év alatt az első fejlesztés díjához hasonló összeget is elkölthetnek további funkciókra. Ez nem kötelező fenntartási költség és nem minden appra érvényes arány: az üzleti bővítésre fordított beruházás.
A hároméves tervben ezért legyen külön sor:
Működés és technikai fenntartás + választott új fejlesztések = indulás utáni teljes technikai költség.
Az ügyfélszolgálat, marketing, tartalomkészítés és más üzleti működési költség ezen felül merülhet fel.
Hogyan számolunk a Petadevnél?
Alapesetben nem kérünk fix havi karbantartási díjat. Megnézzük, mit kell elvégezni, felmérjük a várható ráfordítást, majd egyedi ajánlatot adunk. A fizetős feladatokat előre egyeztetjük.
A garanciális hibajavítás az eredeti specifikációban vállalt működéshez és a megállapodásban érintett operációsrendszer-verziókhoz kapcsolódik, a szerződés feltételei szerint. Egy új funkció vagy egy későbbi platformkövetelmény miatt szükségessé váló frissítés külön feladat. A besoroláshoz először a hiba okát kell megismerni.
Külön megállapodással 24/7 felügyelet is kérhető; ennek már rendszeres díja van. Az elérhetőség, a garantált reakcióidő és a folyamatos felügyelet külön vállalás, amelyet az alkalmazás üzleti szerepéhez igazítunk.
A támogatás részleteit az app üzemeltetés és karbantartás oldalunkon találod.
Mit kérj egy hároméves fenntartási becsléshez?
Az első egyeztetéshez érdemes összegyűjteni:
- Az app funkcióit és fontos integrációit. Például fizetés, térkép, chat, azonosítás vagy AI.
- A jelenlegi technikai állapotot. Milyen rendszerre épül, mikor frissült utoljára, vannak-e ismert hibák?
- A jelenlegi számlákat. Szerver, domain, levelezés, API-k és egyéb szolgáltatások, az esetleges ingyenes kreditekkel együtt.
- A használatot és a növekedési tervet. Aktív felhasználók, tranzakciók, adatforgalom vagy tárolt adatok.
- A működési elvárást. Mekkora problémát jelent egy kiesés és szükséges-e külön felügyelet?
- A tervezett új funkciókat. Ezek költsége különüljön el a meglévő működés fenntartásától.
A használható tervből kiderül, mit fizetsz rendszeresen, mi függ a forgalomtól és mely technikai munkákra kell külön keretet hagyni.
Mennyibe kerülhet a te appod fenntartása?
Küldd el az alkalmazásod rövid leírását vagy áruházi linkjét. Ingyenes első egyeztetésen áttekintjük a várható fenntartási tételeket, vagy segítünk felülvizsgálni a jelenlegi költségeket.
