Alkalmazásfejlesztés Ára 2026: Mit Fizetsz Valójában?

Amikor Minden Ajánlat Mást Mond

Bekérsz három árajánlatot ugyanarra az alkalmazásra. Az első 2,8 millió forint, a második 9 millió, a harmadik 26 millió.

Ugyanaz a leírás, ugyanaz a funkciólista.

Ez nem kivétel, hanem a magyar piac alapállapota.

A legtöbb alkalmazás fejlesztés ár témájú árlista széles sávokat közöl anélkül, hogy megmondaná, pontosan mi van benne: backend? adminfelület? tesztelés? publikálás? Az olvasó marad egy számmal, amiből semmit nem tud kezdeni.

Ez a cikk másképp közelít.

Nem egy varázsszámot adok, hanem egy funkció- és komplexitásalapú költségmodellt, amivel te magad tudsz becslést készíteni, mielőtt bárkivel leülsz tárgyalni.

Végigmegyünk azon, miért nem létezik egységes ár, milyen valós ársávok érvényesek 2026-ban Magyarországon, és mi különbözteti meg az egyszeri fejlesztési díjat a teljes tulajdonlási költségtől (TCO), ami az első évben gyakran 15-25%-kal megemeli a számlát.

Konkrét példákkal dolgozunk: időpontfoglaló app, marketplace, előfizetéses szolgáltatás, belső vállalati eszköz, AI-alapú asszisztens. Mindegyikhez tartozik funkciólista, becsült időigény és nettó ársáv.

A végén kapsz egy használható árajánlatkérési folyamatot, amivel összehasonlítható ajánlatokat tudsz begyűjteni. Nem azért, hogy a legolcsóbbat válaszd, hanem hogy értsd, miért drágább az egyik a másiknál.

Miért Nincs Egységes Alkalmazásár

Egy 12 képernyős app kerülhet 3 millióba és 25 millióba is.

A különbség nem a fejlesztő kapzsiságában van, hanem abban, hogy mi történik a képernyők mögött.

Az alkalmazásfejlesztés árazása három tényezőn múlik: mennyi logikát kell megírni, hány platformra, és ki viseli a bizonytalanság kockázatát.

Nézzük mindhármat.

Funkciók, Nem Képernyők Döntenek

A képernyőszám a legrosszabb becslési alap, amit valaha kitaláltak.

Egy statikus “Rólunk” oldal két óra munka. Egy naptárnézet, ami több szolgáltató szabad időpontjait szinkronizálja időzónakezeléssel és túlfoglalás-védelemmel, két hét.

Ami valóban meghatározza a mobilalkalmazás-fejlesztés munkaigényét:

• Felhasználói folyamatok (user flow): hány lépésből áll egy regisztráció, egy foglalás, egy vásárlás, és mi történik, ha bármelyik lépés meghiúsul. A hibaágak legalább annyi munkát jelentenek, mint a sikeres út.
• Szerepkörök: egy egyfelhasználós app és egy háromszerepkörös rendszer (vásárló, szolgáltató, adminisztrátor) között nem 3x, hanem inkább 4-5x a különbség, mert a jogosultságkezelés minden funkciót érint.
• Üzleti szabályok: lemondási feltételek, kedvezmények, készletkezelés, jutalékszámítás. Ezek nem látszanak a képernyőn, de a backend nagy részét ezek teszik ki.
• Integrációk: minden külső rendszer (fizetés, számlázás, CRM, ERP, térkép, e-mail) külön API-integráció, saját hibakezeléssel és teszteléssel.
• Adatmodell: hány entitás, milyen kapcsolatokkal. Ez határozza meg az adatbázis és felhő infrastruktúra komplexitását, ami később a skálázási költséget is.

Ha egy ajánlatkérés csak képernyőszámot tartalmaz, az árajánlat is találgatás lesz. Írd le inkább, mit csinál a felhasználó, lépésről lépésre.

Natív vagy Cross-Platform?

Natív iOS fejlesztés Swift nyelven, natív Android fejlesztés Kotlinban: két külön kódbázis, két csapat vagy kétszeres időráfordítás. Minden funkciót kétszer kell megírni, kétszer tesztelni, kétszer karbantartani.

A cross-platform fejlesztés Flutterrel egy kódbázisból állít elő natív minőségű alkalmazást mindkét platformra. A gyakorlatban ez 30-45%-kal alacsonyabb fejlesztési költséget és jellemzően harmadával rövidebb átfutási időt jelent egy azonos funkciójú projektnél.

Mikor éri meg mégis a natív út? Ha az app mély hardveres integrációt igényel (fejlett kameravezérlés, AR, Bluetooth-protokollok), ha extrém grafikai teljesítmény kell (3D játék), vagy ha egy nagyvállalat belső szabályzata natív stacket ír elő.

Az esetek nagy részében, tehát üzleti appok, marketplace-ek, foglalórendszerek, előfizetéses termékek esetén a Flutter ugyanazt a felhasználói élményt adja lényegesen olcsóbban.

A CompletApp is emiatt dolgozik egységesen Flutter alapon.

Fix Ár, Óradíj vagy Mérföldkő?

Az árazási modell dönti el, ki fizeti a meglepetéseket. Ez legalább olyan fontos, mint maga az összeg.

• Fix ár, fix scope: a fejlesztő viseli a becslési kockázatot. Cserébe általában 10-20% kockázati felárat épít az árba, és a scope-on kívüli kéréseket külön számlázza. Előre kiszámítható költség, ez a legbiztonságosabb választás, ha a terjedelmet jól le tudod írni.
• Óradíj (time & material): te viseled a kockázatot. Magyar piacon 2026-ban jellemzően 12 000-25 000 Ft/óra nettó egy tapasztalt fejlesztőnél, 25 000-45 000 Ft/óra egy ügynökségnél. Rugalmas, de a végösszeg nyitott.
• Mérföldkő-alapú: a kettő közötti kompromisszum. Fázisonként rögzített ár és szállítási tartalom, minden mérföldkő után döntési pont. Ha egy stúdió kilépési garanciát is ad az első mérföldkő után, az érdemben csökkenti a belépési kockázatodat.

A csapat típusa és a földrajz tovább torzít. Egy budapesti freelancer 8 000-15 000 Ft/óra körül dolgozik, egy hazai stúdió 15 000-30 000 Ft/óra, egy nyugat-európai ügynökség 100-150 EUR/óra.

Ugyanaz az app Münchenben háromszor annyiba kerül, mint Budapesten.

Árkategóriák 2026-ban

Az alábbi táblázat magyar piaci, nettó árakat tartalmaz 2026-ra, Flutter-alapú cross-platform fejlesztést feltételezve. A natív iOS+Android párhuzamos fejlesztés ezekhez képest nagyjából 1,4-1,8x szorzót jelent.

Néhány magyarázat a számokhoz.

Az MVP-kategória alsó vége akkor reális, ha a scope tényleg egyetlen fő felhasználói út köré épül, sablonosított, de nem sablon kinézettel. A CompletApp például 4 hetes, fix áras MVP-modellben dolgozik, pont ezért, mert a validációhoz nem kell 30 képernyő.

A marketplace azért ugrik kategóriát, mert nem egy app, hanem három rendszer: vásárlói oldal, eladói oldal és a köztük lévő elszámolás. A fizetésmegosztás (split payment) önmagában 400 000-1 200 000 Ft közötti tétel.

Mi Emeli Meg Az Árat

Néhány funkció aránytalanul sokat visz el a büdzséből. Érdemes ismerni őket, mielőtt bekerülnek a specifikációba.

• Fizetési rendszer: Stripe alapintegráció 300 000-700 000 Ft, előfizetés-kezelés RevenueCatnél az App Store és Google Play számlázási sajátosságaival együtt 700 000-1 500 000 Ft. Ide jön a próbaidőszak, lemondás, visszatérítés és a lejárt fizetés kezelése.
• Térkép és helymeghatározás: 400 000-1 200 000 Ft, plusz folyamatos Google Maps API-díj, ami forgalmas appnál havi tízezres-százezres nagyságrendbe fut.
• Valós idejű chat: 800 000-2 500 000 Ft, ha képküldés, olvasottság-jelzés, moderáció és értesítések is kellenek.
• Videó- és médiakezelés: feltöltés, transzkódolás, CDN-kiszolgálás 600 000-2 000 000 Ft, majd tárolási és sávszélesség-költség havonta.
• AI-integráció: az egyszeri fejlesztés 800 000-3 000 000 Ft, de ez a jéghegy csúcsa.

Az AI-nál különösen fontos a folyamatos költség. Egy OpenAI vagy Claude alapú funkció esetén számolni kell az API-használati díjjal (ami a felhasználószámmal lineárisan nő), a prompt- és válaszminőség monitoringjával, az adatvédelem és GDPR megfelelés dokumentálásával, valamint a modellváltásokkal járó újrahangolással.

Egy közepes forgalmú AI-funkció havi API-költsége 50 000 és 500 000 forint között mozoghat. Ezt a tételt a legtöbb árajánlat egyáltalán nem említi.

És van egy tétel, amit szinte minden kalkuláció alábecsül: a frontend és backend fejlesztés arányát.

A látható felület általában a munka 40-50%-a. A backend, az adatmodell, az API-k, az adminfelület és a DevOps együtt a projekt 30-40%-át teszi ki, a minőségbiztosítás és tesztelés további 10-15%-ot.

Ha egy ajánlat feltűnően olcsó, jó eséllyel ebből a 30-40%-ból hiányzik valami. Kérdezd meg konkrétan: van benne adminfelület? Ki és hogyan tölti fel a tartalmat? Mi történik, ha ezer felhasználó helyett százezer lesz?

A Fejlesztésen Túl: Teljes Költség

A fejlesztési ár a jéghegy csúcsa.

Egy alkalmazás hároméves teljes tulajdonlási költsége jellemzően a kezdeti fejlesztési díj 1,5-2-szerese.

Nettó vs. Bruttó Ár

Magyarországon a fejlesztési szolgáltatásra 27% ÁFA rakódik. Egy 8 000 000 Ft nettó ajánlat 10 160 000 Ft bruttó, ami 2 160 000 forint különbség.

ÁFA-alanyként ez visszaigényelhető, tehát a nettó ár a valós költséged.

Alanyi adómentes vállalkozásként vagy magánszemélyként viszont a bruttó összeggel kell terveznie, és ez sok költségvetést borít fel az utolsó pillanatban.

Kérd írásban, hogy az ajánlat nettó vagy bruttó, és hogy tartalmazza-e a harmadik feles díjakat. Az Apple Developer Program évi 99 USD, a Google Play fejlesztői fiók egyszeri 25 USD, ezek jellemzően nincsenek benne a fejlesztői árban.

Éves Karbantartás és Üzemeltetés

A szokásos “számolj a fejlesztési ár 15-25%-ával évente” tanács igaz, de önmagában semmit nem magyaráz. Bontsuk tételekre, mi is ez valójában egy 8 millió forintos appnál.

• Operációs rendszer-frissítések: az Apple és a Google évente egyszer nagy verziót ad ki. Az SDK-frissítés, kompatibilitási javítás és újratesztelés 200 000-500 000 Ft évente, akkor is, ha az appon egyetlen új funkció sem készül.
• Hibajavítás: az élesben felmerülő hibák javítása, crash-riportok kezelése. Reálisan 150 000-400 000 Ft/év egy stabil appnál.
• Biztonsági frissítések: a használt könyvtárak sérülékenységeinek javítása, hitelesítési és titkosítási karbantartás. 150 000-350 000 Ft/év.
• App store megfelelőség: adatvédelmi címkék, engedélykezelés, korhatár-besorolás, új store-szabályok követése. 100 000-250 000 Ft/év, publikálásonként.
• Infrastruktúra: Firebase/Supabase, tárhely, CDN, e-mail- és push-szolgáltatás. Kis appnál havi 15 000-40 000 Ft, tíz-húszezer aktív felhasználónál havi 80 000-300 000 Ft.
• Új funkciók: a legnagyobb tétel, de ez már befektetés, nem karbantartás. Külön büdzsé, külön döntés.

Ha összeadod, egy 8 milliós app puszta életben tartása évi 1,2-2 millió forint körül alakul, új funkciók nélkül. Ezt érdemes már az első üzleti tervbe beírni.

Kié a Forráskód és az Adatok?

Ez a szerződés legfontosabb bekezdése, és a legtöbben átugorják. Ha a forráskód nem a tiéd, nem tudsz fejlesztőt váltani, és minden jövőbeli módosítás egyetlen szolgáltatótól függ.

Amit írásban tisztázz, mielőtt aláírsz:

• Forráskód tulajdonjoga: teljes kifizetés után átszáll-e rád, és milyen formában (privát Git-repository átadás, teljes commit-történettel).
• Design fájlok: a Figma-projekt, ikonkészlet, betűtípus-licencek szerkeszthető formában.
• Fejlesztői fiókok: az Apple és Google fiók a te céged nevén legyen, ne a fejlesztőén. Utólagos átemelés hetekbe telhet.
• Felhasználói adatok: az adatbázis a te tulajdonod, exportálható formátumban, és te legyél a GDPR szerinti adatkezelő.
• Infrastruktúra-hozzáférés: a Firebase/Supabase projekt, domain, DNS és analitikai fiókok a te tulajdonodban.

Jó gyakorlatként érdemes olyan partnert választani, aki ezt alapból vállalja. A CompletApp például teljes kifizetés után 100%-os kódtulajdont ad át, ami gyakorlatilag kizárja a vendor lock-int, és növeli a projekt későbbi eladhatóságát is (befektetői due diligence-nél ez kemény kérdés).

Hogyan Kérj Pontos Árajánlatot

Az árajánlat minősége az ajánlatkérés minőségén múlik. Egy féloldalas ötletleírásra senki nem tud pontos árat adni, csak széles sávot, ami később mindkét félnek fáj.

1. Írd le a felhasználói folyamatokat, ne a képernyőket. Mondatokban rögzítsd: “A felhasználó regisztrál e-maillel, kiválaszt egy szolgáltatót, lát egy naptárat a szabad időpontokkal, foglal, kap egy e-mailes és egy push visszaigazolást, 24 órán belül díjmentesen lemondhat.” Ez a leírás minden fejlesztőnek ugyanazt jelenti, egy képernyőlista nem.
2. Sorold fel a szerepköröket és a jogosultságaikat. Ki lát mit, ki mit módosíthat, ki kap értesítést. Ha van adminisztrátor, írd le, mit kell tudnia az adminfelületnek: tartalomkezelés, felhasználókezelés, riportok, exportok. Ez a rész szokott a legtöbbet csúszni menet közben.
3. Határozd meg az MVP-scope-ot, és tudatosan hagyj ki funkciókat. Kérdezd meg minden egyes funkciónál: ha ez hiányzik, meg tudom-e tudni, hogy az emberek használnák-e a terméket? Ha igen, ki vele. A chat, a közösségi funkciók, a gamifikáció és a többnyelvűség szinte mindig várhat a validáció utánra.
4. Kérj funkciónkénti bontást írásban. Ne egy összeget kérj, hanem tételes listát: minden funkció mellett becsült óra vagy nap, és ár. Így két ajánlat összehasonlíthatóvá válik, és azonnal látszik, ha az egyikből hiányzik a backend vagy a tesztelés.
5. Rögzíts mérföldköveket és elfogadási kritériumokat. Mérföldkövenként legyen szállítandó (design, működő MVP-build, store-ra beadott verzió) és mérhető elfogadási feltétel (“a foglalás visszaigazoló e-mailje 30 másodpercen belül megérkezik”). Bizonytalan kritériumokból lesznek a vitás átadások.
6. Tisztázd a változáskezelést. Kérdezd meg, hogyan kezelik a change requestet: mennyi idő alatt adnak rá árat, van-e minimális tétel, és beleférhet-e a meglévő keretbe csere útján. Fix áras projekteknél ez a pont dönti el, mennyire lesz rugalmas az együttműködés.
7. Kérdezz rá a technológiai döntésre és a garanciákra. Miért Flutter vagy miért natív? Mi a fix ár és fix scope pontos tartalma? Van-e kilépési lehetőség az első mérföldkő után? A CompletApp modellje például 4 hetes, fix áras MVP, ahol az első mérföldkő után az ügyfél fizetés nélkül kiszállhat, ha nem elégedett. Ez a fajta garancia jó viszonyítási alap más ajánlatok megítéléséhez is.
8. Döntsd el, kell-e egyáltalán egyedi fejlesztés. Ha a folyamatod belefér egy kész SaaS-be vagy no-code eszközbe, havi 30-100 ezer forintból elindulhatsz. Egyedi fejlesztés akkor indokolt, ha a folyamatod versenyelőnyt jelent, ha az adat a tiéd kell hogy legyen, vagy ha a sablonmegoldás korlátai már mérhető bevételt visznek el.

A megtérülésnél három számot érdemes kiszámolni. Mennyi munkaórát spórol havonta a csapatnak (óra × bérköltség), mennyivel javítja a konverziót vagy a visszatérő vásárlást, és nyit-e új bevételi csatornát (előfizetés, jutalék, prémium funkció).

Egy 8 millió forintos belső vállalati app, ami tíz kollégának havi 12 órát spórol, körülbelül 14-18 hónap alatt térül meg.

Ez reális elvárás, a “három hónap alatt megtérül” ígéret nem az.

Gyakori Kérdések

Mennyibe Kerül Egy Saját App?

Egy saját alkalmazás 2026-ban nettó 2,5 és 45 millió forint között kerül, a komplexitástól függően.

Egy validációs célú MVP 2,5-6 millió, egy teljes üzleti alkalmazás fizetéssel és adminfelülettel 6-15 millió, egy marketplace vagy AI-alapú enterprise rendszer 15 millió felett indul. A pontos árat a felhasználói folyamatok, a szerepkörök és az integrációk száma határozza meg.

Mennyibe Kerül Egy App Magyarországon?

Magyarországon egy átlagos üzleti alkalmazás nettó 6-15 millió forint, ami nagyjából a nyugat-európai árak harmada-fele.

Egy budapesti stúdió óradíja 15 000-30 000 Ft nettó, szemben a német vagy holland ügynökségek 100-150 eurós óradíjával. A 27%-os ÁFA-t érdemes külön kalkulálni, ha nem tudod visszaigényelni.

Mennyi Idő Alatt Készül El?

Egy fix scope-ú MVP 4-8 hét alatt elkészül, egy standard üzleti alkalmazás 2-4 hónap, egy komplex rendszer 4-9 hónap. Ehhez jön az App Store és Google Play felülvizsgálat, ami 1-7 nap.

A határidőt leggyakrabban nem a fejlesztés, hanem az ügyféloldali döntések és tartalomszállítás késése csúsztatja.

Mennyibe Kerül Egy Egyszerű App?

Egy egyszerű, egyfunkciós alkalmazás nettó 2,5-4 millió forintból elkészíthető cross-platform fejlesztéssel. Ez tartalmaz belépést, 6-10 képernyőt, egy fő felhasználói folyamatot, Firebase vagy Supabase backendet, alap adminfelületet és a store-publikálást.

Ha fizetés, chat vagy térkép is kell, azonnal a 4-6 milliós sávba lépsz.

Miért Ilyen Drága Egy App?

Mert a látható felület a munkának csak a fele.

A backend, az adatmodell, az API-k, az adminfelület és a DevOps a projekt 30-40%-a, a tesztelés további 10-15%, és mindezt két platformon kell működésre bírni. Egy 8 millió forintos app mögött jellemzően 350-450 szakértői munkaóra áll.

Webapp vagy Mobilapp Olcsóbb?

A webapp jellemzően 30-40%-kal olcsóbb belépő pont, mert nincs store-folyamat, nincs kétplatformos tesztelés, és a frissítés azonnal él.

Cserébe nem kapsz App Store és Google Play jelenlétet, gyengébbek a push értesítések iOS-en, és nincs offline mód.

Sok termék jól indul reszponzív webappal, majd validáció után épít mobilalkalmazást.

Mennyi Az Éves App Fenntartás?

Az éves fenntartás a fejlesztési ár 15-25%-a, tehát egy 8 milliós appnál nettó 1,2-2 millió forint. Ebben van az operációs rendszer-frissítésekhez igazítás, hibajavítás, biztonsági patch-ek, store-megfelelőség és az infrastruktúra (Firebase, tárhely, push, e-mail).

Az új funkciók fejlesztése ezen felüli, külön tervezendő büdzsé.

Hogyan Csökkenthető a Fejlesztési Költség?

A leghatékonyabb módszer a scope szűkítése valódi MVP-re: csak az a funkció maradjon, ami nélkül nem tudod validálni az üzleti feltételezésedet. Ezen felül válassz cross-platform fejlesztést natív helyett (30-45% megtakarítás), használj kész backend szolgáltatásokat (Firebase, Supabase), és fázisold a fejlesztést, hogy a bevétel finanszírozza a következő kört.

Záró Gondolatok

Két tiszta döntési út van.

Ha a cél gyors piaci validáció, egy fix áras, fix scope-ú, cross-platform MVP a legalacsonyabb kockázatú lépés: 4-8 hét, 2,5-6 millió forint, és a végén valódi felhasználói adatod lesz feltételezések helyett.

Ha viszont sokfelhasználós, integrációkkal terhelt rendszert építesz, ne kérj árat előbb, mint hogy lenne egy fizetett discovery fázisod. Egy 300-800 ezer forintos felmérés, amiből adatmodell, folyamatábra és funkciólista születik, rendszeresen több millió forintnyi félrefejlesztést előz meg.

És egy dolog, amit érdemes megjegyezni: a legolcsóbb ajánlat szinte soha nem a legolcsóbb projekt.

A legátláthatóbb ajánlat az, ahol funkciónként látod a bontást, ahol a backend és a tesztelés is tételesen szerepel, és ahol írásban rögzítik, kié lesz a forráskód.

Ne azt kérdezd, mennyibe kerül az app. Azt kérdezd, mi van benne, és mi nincs.

Egyetlen következő lépés: mielőtt bárkitől ajánlatot kérnél, ülj le egy órára, és írd le a három legfontosabb felhasználói folyamatot mondatokban, elejétől a végéig. Ez a lista lesz az az egy dokumentum, amitől az ajánlatok végre összehasonlíthatóvá válnak.