A Rejtett Költség, Amire Senki Nem Készül
Egy mobilalkalmazás legdrágább éve ritkán az első. A fejlesztési számla kifizetésével a költségek nem érnek véget.
Ekkor kezdődnek igazán.
A fejlesztési ár csak az induló beruházás.
Utána jönnek az iOS frissítések, az Android target API követelmények, a szerverszámlák, a hibajelentések és az új funkciókra vonatkozó kérések. Ezek évekig futnak, és 3-5 év alatt gyakran meghaladják az eredeti fejlesztési költséget.
Iparági becslések szerint a szoftverkarbantartás egy rendszer teljes életciklus-költségének 50-80%-át teszi ki. A legtöbb megrendelő mégis csak a fejlesztési ajánlatokat hasonlítja össze.
A karbantartás egy sor a szerződés végén… ha egyáltalán szerepel benne.
A magyar nyelvű útmutatók többsége sem segít sokat. Jellemzően egyetlen kiragadott számot közölnek („évente a fejlesztési költség 15-20%-a” vagy „havi 50 000 Ft-tól”), de nem mutatják meg, mi mozgatja a számlát.
Egy százalék nem terv.
Csak egy tipp.
Ez az útmutató más megközelítést használ: egy scope-alapú, forintban számoló modellt, amely külön kezeli a hibajavítást, az üzemeltetést és az új funkciófejlesztést. Így látható, melyik tételnél lehet spórolni, és melyiknél kockázatos.
Az alábbiakban végigmegyünk azon, mire terjednek ki az app karbantartási költségek, mennyit érdemes rájuk szánni 2026-ban három tipikus apptípusnál, mitől szalad el a számla, és hogyan ellenőrizheted egy ajánlat tartalmát, mielőtt aláírod.
Mi Tartozik a Karbantartásba
A „karbantartási díj” a szoftveripar egyik legkevésbé átlátható tétele. Sok ajánlat egyetlen havi összeget ad meg, és nem derül ki belőle, pontosan mit kapsz érte.
Valójában négy, jól elkülöníthető költségcsoport létezik. Ha ezeket egy homályos díj alá mossák össze, nem tudod összehasonlítani az ajánlatokat, és azt sem látod, hová megy a pénzed.
- Hibajavítás: a meglévő funkciók hibáinak feltárása és kijavítása, beleértve a crash monitoring alapján azonosított összeomlásokat és a javítások utáni regressziós tesztelést.
- Üzemeltetés: mindaz, ami az app futásához kell, vagyis cloud hosting, backend infrastruktúra, adatbázis, mentések, monitorozás és a külső szolgáltatások API-költségei.
- Felhasználói támogatás: a felhasználói megkeresések kezelése, az app store értékelésekre adott válaszok és a második szintű technikai support, amikor egy hiba nem reprodukálható egyszerűen.
- Új funkciófejlesztés: minden, ami új viselkedést ad az apphoz. Ez már nem karbantartás, hanem továbbfejlesztés, ezért külön keretből érdemes finanszírozni.
Hibajavítás és Garancia
Nem minden hiba egyforma, és nem mindegyikért kell fizetni. A legfontosabb különbség a garanciális hiba és a környezeti változás miatt fellépő hiba között húzódik.
- Garanciális hiba: a fejlesztő saját hibája, amelyet a szerződésben rögzített garanciaidőn belül (Magyarországon jellemzően 3-6 hónap) díjmentesen kell javítania.
- OS-kompatibilitási javítás: egy új iOS vagy Android verzió okozta hiba, amely a fejlesztés idején nem létezett. Ez nem a fejlesztő hibája, ezért fizetős karbantartási tétel.
- Függőségfrissítés: a külső könyvtárak és SDK-k (Firebase, fizetési modulok, analitika) rendszeres frissítése, mert a régi verziók idővel elavulnak vagy biztonsági rést hordoznak.
- Regressziós tesztelés: minden javítás után ellenőrizni kell, hogy a módosítás nem rontott-e el mást. Ez a hibajavítási órák 20-30%-át is kiteheti.
- Crash monitoring: eszközök, például Firebase Crashlytics vagy Sentry, amelyek valós időben jelzik az összeomlásokat, így a hibák a felhasználói panaszok előtt kiderülnek.
Üzemeltetés és Infrastruktúra
Az üzemeltetés az a költség, amely akkor is fut, ha senki nem nyúl a kódhoz. Ez a mobilalkalmazás üzemeltetés „rezsije”, és a felhasználószámmal együtt nő.
- Cloud hosting: AWS, Google Cloud vagy Azure szerverek díja. Egy kis forgalmú MVP-nél ez havi 10 000-30 000 Ft, egy több ezer aktív felhasználós appnál ennek többszöröse.
- Backend infrastruktúra karbantartása: szerver-operációsrendszer patchek, adatbázis-mentések, tanúsítványok megújítása és a naplók kezelése.
- API-költségek: használatalapú díjak térképszolgáltatásért, SMS-küldésért, push értesítésekért vagy AI-modellekért, amelyek egy sikeres kampány után akár megduplázódhatnak.
- Fejlesztői fiókok: az Apple Developer Program évi 99 USD, a Google Play fejlesztői fiók egyszeri 25 USD. Kis tétel, de ha lejár, az app eltűnhet a boltból.
- App store publikálás: minden új verzió beküldése, a metaadatok, képernyőképek és adatvédelmi nyilatkozatok frissítése, valamint az esetleges elutasítások kezelése.
Új Funkció vs Karbantartás
Itt keletkezik a legtöbb vita megrendelő és fejlesztő között. Az egyszerű szabály: ha a meglévő viselkedést tartja életben, karbantartás; ha új viselkedést ad, fejlesztés.
- Karbantartás: a bejelentkezés nem működik egy iOS frissítés után, és a fejlesztő helyreállítja. A funkció ugyanaz, csak újra működik.
- Fejlesztés: a megrendelő Google-bejelentkezést szeretne a meglévő e-mailes mellé. Ez új funkció, külön becsléssel és külön kerettel.
- Szürke zóna: kötelező külső változások, például egy Google Play target API emelés, amely érdemi kódmódosítást igényel. Ezeket a szerződésben előre érdemes besorolni, különben minden alkalommal vita lesz belőlük.
- Gyakorlati tipp: tarts külön havi vagy negyedéves fejlesztési keretet. Ha a karbantartási órákból finanszírozod az új funkciókat, a hibajavítás csúszik, és ezt a felhasználók veszik észre először.
Mennyibe Kerül Forintban 2026-ban
Egy egyszerű MVP és egy komplex üzleti app karbantartása között akár tízszeres különbség is lehet havonta.
Ugyanaz a szó, egészen más munka.
Az alábbi táblázat 2026-os magyarországi piaci tapasztalatokon alapuló, irányadó sávokat mutat. A havi karbantartás a hibajavítást, az OS-kompatibilitást és a függőségfrissítést fedi le, a havi üzemeltetés pedig a szerver- és szolgáltatási díjakat.
Az árak nettó összegek, új funkciófejlesztés nélkül.
| App típus | Havi karbantartás (HUF) | Havi üzemeltetés (HUF) | Jellemző extra tételek |
|---|---|---|---|
| Egyszerű MVP (1-2 integráció, egy felhasználói szerep) | 80 000-150 000 Ft | 15 000-40 000 Ft | Fejlesztői fiókok díja, éves OS-kompatibilitási frissítés, alap crash monitoring |
| Közepes üzleti app (3-5 integráció, 2-3 jogosultsági szint) | 200 000-450 000 Ft | 50 000-150 000 Ft | Fizetési szolgáltató díjai, push és e-mail szolgáltatás, admin felület karbantartása |
| Komplex több integrációs app (6+ integráció, összetett szerepkörök) | 500 000-1 200 000+ Ft | 150 000-500 000 Ft | ERP vagy CRM szinkron, SLA szerinti ügyelet, terheléses tesztek, külső biztonsági audit |
| Szabályozott iparági app (fintech, egészségügy, energetika) | 1 200 000+ Ft | 400 000-1 000 000+ Ft | Megfelelőségi dokumentáció, rendszeres penetrációs teszt, naplózási és adatmegőrzési előírások |
Feltűnő, hogy a sávokat nem a funkciók száma határozza meg. Egy 30 képernyős katalógusapp olcsóbban karbantartható lehet, mint egy 8 képernyős app, amely három külső rendszerrel kommunikál.
A komplexitást három tényező növeli igazán:
- Az integrációk száma: minden külső API egy újabb pont, ahol a másik fél változtathat valamit, és az app előzetes figyelmeztetés nélkül elromolhat.
- A felhasználói jogosultsági szintek: egy admin, egy menedzser és egy végfelhasználói szerep háromszor annyi tesztesetet jelent minden módosításnál.
- A támogatott OS-verziók száma: ha az app iOS 15-től és Android 8-tól felfelé fut, minden javítást 5-6 rendszerverzión kell ellenőrizni. Ha csak az utolsó három verziót támogatod, a tesztelési idő érezhetően csökken.
Az Ökölszabály Csapdái
A legelterjedtebb ökölszabály szerint az éves karbantartás a fejlesztési költség 15-20%-a.
Kényelmes szám.
És gyakran félrevezető.
Vegyünk két appot, amelyek fejlesztése egyaránt 10 millió forintba került. Az egyik egy tartalomközpontú app egyetlen backenddel, a másik egy foglalási rendszer hat integrációval. A 15%-os szabály mindkettőre évi 1,5 millió forintot, vagyis havi 125 000 Ft-ot adna.
Az első appnál ez bőven elég.
A másodiknál a valós igény inkább havi 350 000 Ft körül mozog, mert minden integrációs partner évente legalább egyszer módosít valamit. A százalék tehát az egyiknél túlbecsül, a másiknál alulbecsül.
Van egy második csapda is.
Ha a fejlesztés olcsó volt (például egy alacsony óradíjú külföldi csapat készítette, vagy egy sablonból épült), a százalékos alap eleve torz.
A rosszul dokumentált, teszt nélküli kód karbantartása többe kerül, nem kevesebbe.
A karbantartási költséget a scope határozza meg, nem a fejlesztési ár. Integrációkat, szerepköröket és támogatott OS-verziókat kell számolni, nem százalékot.
Mitől Nő a Számla
Miért kerül egy kétszer bonyolultabb app karbantartása gyakran háromszor-négyszer annyiba?
Mert a komplexitás nem összeadódik, hanem szorzódik.
A karbantartási díj nem lineárisan nő a funkciókkal, hanem a technikai komplexitással akár exponenciálisan. Minden új elem nemcsak önmagában igényel figyelmet, hanem az összes meglévővel való kapcsolatában is.
Integrációk és Technikai Adósság
Egy egyszerű számítás mindent megmagyaráz.
Két integráció között egyetlen kapcsolódási pont van, de hat integráció között már 15 lehetséges kölcsönhatás. Ha a fizetési szolgáltató módosít, az érintheti a számlázót, a CRM-et és a push értesítéseket is.
Ehhez jön a technikai adósság: minden gyors megoldás, kihagyott teszt és elhalasztott frissítés, amely a fejlesztés során felhalmozódott.
Úgy működik, mint egy hitelkártya.
A határidő előtti gyorsítás most olcsó, de a kamatot minden későbbi módosításnál megfizeted.
A gyakorlatban ez így néz ki: egy olyan javítás, amely tiszta kódbázison 4 óra, egy adósságokkal terhelt projekten 12-16 óra is lehet. A fejlesztőnek előbb meg kell értenie a dokumentálatlan logikát, aztán kézzel tesztelnie mindent, mert nincs automatizált teszt.
Az elhalasztott függőségfrissítés a technikai adósság legdrágább formája. Ha egy app két évig nem frissít semmit, a következő kötelező lépés (például egy új Android target API) már nem egy apró módosítás, hanem több hetes migráció.
Olcsóbb-e a Flutter Karbantartása
A rövid válasz: sokszor igen, de nem automatikusan. A Flutter cross-platform megoldás egy kódbázist tart karban két platform helyett, ami a felülethez kötött hibáknál valóban megtakarítást hoz.
A megtakarítás ott fogy el, ahol az app mélyen a hardverhez nyúl. Bluetooth-eszközök, háttérben futó helymeghatározás, HealthKit vagy otthoni képernyős widgetek esetén platformspecifikus kód kell, amelyet a Flutter mellett külön karban kell tartani.
Ráadásul a pluginek gyakran késve követik az új iOS frissítéseket.
Van egy rejtett tétel is: maga a keretrendszer.
A Flutter főverzió-váltásai néha a függőségek tömeges frissítését igénylik, ami egy nagyobb projektnél napokat vehet igénybe.
Egy UI-központú üzleti appnál, például egy foglalási vagy hűségprogramos alkalmazásnál, a Flutter karbantartása 25-40%-kal olcsóbb lehet, mint két natív iOS és Android app fenntartása. Egy erősen hardverfüggő appnál viszont a különbség eltűnhet, sőt meg is fordulhat.
Biztonsági és Adatvédelmi Frissítések
Az alkalmazásbiztonság nem egyszeri feladat.
Az OWASP Mobile Top 10 listán szereplő sérülékenységek jelentős része elavult függőségekből és hibás adattárolásból ered, ezért a rendszeres frissítés közvetlen biztonsági kérdés.
A szabályozói oldal is szigorodik.
- június 28. óta az Európai Akadálymentesítési Irányelv (EAA) kötelező az e-kereskedelmi és banki szolgáltatásokra, ami sok magyar appnál utólagos módosításokat követelt meg. A NIS2-hez kapcsolódó magyar kiberbiztonsági szabályozás pedig bizonyos ágazatokban dokumentált biztonsági folyamatokat ír elő.
Az áruházak sem várnak.
Az Apple adatvédelmi manifesztet és pontos adatkezelési címkéket kér, a Google Play pedig a Data safety szekció naprakészségét ellenőrzi. Egy elmaradt nyilatkozat-frissítés is a következő verzió elutasításához vezethet.
Hogyan Válassz Karbantartási Modellt
Nincs univerzálisan jó karbantartási modell.
Egy belső használatú leltárappnak és egy webshop mobilalkalmazásának teljesen más kockázati profilja van.
Az egyszerű döntési keret a kockázatból indul ki: mennyibe kerül egy órányi kiesés, és milyen gyakran változik az app környezete?
- Alacsony kockázatú, stabil app: kevés integráció, nem generál közvetlen bevételt, egy napos kiesés kellemetlen, de nem káros. Ide elég az eseti, óradíjas javítás.
- Növekvő, közepes kockázatú app: aktív felhasználói bázis, 3-5 integráció. Itt egy havi órakeret a jó választás, amely garantál rendelkezésre álló kapacitást, de nem kötelez túlzott fix díjra.
- Bevétel-kritikus, sok integrációs app: minden óra kiesés pénzben mérhető veszteség. Ide havi átalány és írásban rögzített SLA és támogatási szint kell, garantált reakcióidőkkel.
Bármelyik modellt választod, az ajánlatban három sornak kell külön szerepelnie: a fix havi rendelkezésre állási díjnak, a ténylegesen felhasznált fejlesztői óráknak és a külső szolgáltatók változó díjainak. Ha ezek egy összegben jelennek meg, nem tudod ellenőrizni, mire fizetsz.
Átalány, Óradíj vagy Projekt
A három elterjedt elszámolási forma mást optimalizál. Az egyik kiszámíthatóságot ad, a másik rugalmasságot, a harmadik pedig fix árat egy konkrét feladatra.
- Havi átalány: fix összeg egy meghatározott órakeretért és rendelkezésre állásért. Kiszámítható költségvetés és garantált reakcióidő, de ha egy hónapban nincs hiba, a fel nem használt órák jellemzően elvesznek. Kérdezd meg, átvihetők-e a következő hónapra.
- Óradíj: csak a ténylegesen elvégzett munkáért fizetsz. 2026-ban Magyarországon a szabadúszó mobilfejlesztők jellemzően 12 000-20 000 Ft/óra, az ügynökségek 18 000-30 000 Ft/óra nettó díjjal dolgoznak. Hátránya, hogy nincs garantált kapacitás, sürgős hibánál sorban állhatsz.
- Projektalapú díj: fix ár egy jól körülhatárolt feladatra, például egy éves OS-kompatibilitási frissítésre vagy egy target API migrációra. Ideális a tervezhető, egyszeri munkákhoz, de folyamatos hibajavításra nem alkalmas.
Mire Figyelj az Ajánlatban
A legtöbb karbantartási vita nem a munka minőségén, hanem a szerződés homályos pontjain csúszik el. Ezeket a kérdéseket még az aláírás előtt tisztázd:
- Tételes bontás: külön szerepel-e a hibajavítás, az üzemeltetés és az új fejlesztés? Ha csak egy százalék vagy egy összeg van, kérj bontást.
- Reakció- és javítási idő: mit jelent a „kritikus hiba”, és mennyi idő alatt reagálnak rá? Bevétel-kritikus appnál a 4 órán belüli reakció és a 24 órán belüli javítás reális elvárás.
- OS-frissítések besorolása: az éves iOS frissítés és az Android target API emelés benne van-e az átalányban, vagy külön projektként számlázzák?
- Külső költségek kezelése: a cloud hosting és az API-díjak a te fiókodon futnak, vagy a fejlesztő számlázza tovább felárral? A saját fiók átláthatóbb.
- Hozzáférések és forráskód: a forráskód, az áruházi fiókok és a szerverhozzáférések a te tulajdonodban vannak-e? Ha nem, egy szolgáltatóváltás hónapokig tarthat.
- Felmondási feltételek: mekkora a felmondási idő, és vállal-e a fejlesztő átadási dokumentációt egy új partner felé?
Hároméves TCO Lépésről Lépésre
A teljes birtoklási költség (TCO) mutatja meg, mennyibe kerül valójában az app. Az alábbi példa egy 12 millió forintos fejlesztési költségű, közepes üzleti appal számol.
- Rögzítsd a fejlesztési alapot. A példában ez 12 000 000 Ft, amely egyszeri tétel, és a TCO kiindulópontja.
- Számold ki a karbantartást. Havi 300 000 Ft-os átalánnyal ez évi 3 600 000 Ft, három év alatt 10 800 000 Ft.
- Add hozzá az üzemeltetést. Havi 100 000 Ft hosting és infrastruktúra, plusz kb. 40 000 Ft API-díj és fiókköltség, ami évi 1 680 000 Ft, három év alatt 5 040 000 Ft.
- Tervezz fejlesztési keretet. Évi 3 000 000 Ft új funkciókra, három év alatt 9 000 000 Ft.
- Képezz tartalékot. A működési költségek (24 840 000 Ft) 15%-a, azaz kb. 3 730 000 Ft váratlan migrációkra és szabályozói változásokra.
- Összesítsd. A hároméves TCO kb. 40 570 000 Ft, amelyből csak a karbantartás és az üzemeltetés (15 840 000 Ft) már több, mint az eredeti fejlesztés.
Mit Tegyél Most
Ha egyetlen dolgot viszel magaddal ebből az útmutatóból, ez legyen: mielőtt aláírsz egy ajánlatot, kérd tételes bontását hibajavításra, üzemeltetésre és fejlesztésre. Ne fogadj el egyetlen összevont százalékot vagy átalányt bontás nélkül.
Egy jó fejlesztő ezt gond nélkül megadja.
Ha valaki ódzkodik tőle… az már önmagában információ.
A döntés maga egyszerűbb, mint amilyennek látszik.
Korlátozott budget és stabil MVP esetén elég az eseti, óradíjas javítás, kiegészítve egy évi egyszeri OS-kompatibilitási frissítéssel.
Bevétel-generáló, sok integrációs app esetén viszont havi átalány és írásban rögzített SLA szükséges, mert egy napnyi kiesés többe kerülhet, mint egy egész évnyi karbantartási díj.
Bármelyik utat választod, számolj háromévente, ne havonta.
A teljes birtoklási költség mutatja meg, mire vállalkozol valójában.
Ha tételes, forintban átlátható karbantartási tervet szeretnél, amelyet már a fejlesztéssel együtt terveznek meg, a CompletApp ingyenes 30 perces konzultációján erre írásos ajánlatot kaphatsz. Így az app karbantartási költségek nem utólagos meglepetésként, hanem tervezett tételként jelennek meg a költségvetésedben.
