Mennyibe kerül egy app? Applikáció fejlesztés költségei 2026

Amikor ugyanarra a kétoldalas ötletleírásra, briefre kapsz egy 3 milliós és egy 30 milliós ajánlatot is joggal merül fel a kérdés, hogy ez hogy lehetséges? A helyzet az, hogy egyik sem feltétlenül kamu. Az app ára attól függ, mit kell tudnia a rendszernek, hány platformon fut, milyen más rendszerekkel kell összekötni, és ki készíti. Ezt a négy dolgot kell látnod ahhoz, hogy az ajánlatokat egyáltalán össze tudd hasonlítani.

Ebben a cikkben leírjuk, miből állnak össze az applikáció fejlesztés költségei, milyen sávokkal számolj a hazai piacon, mikor éri meg egyáltalán belevágni, és mennyibe kerül az app azután, hogy elkészült. Fix árat nem fogunk mondani, mert olyan nincs, de a végére tudni fogod, hogyan értékelj egy ajánlatot, esetleg mit kérdezz vissza, ha valami hiányzik belőle.

Miért nincs fix ára egy alkalmazásnak?

Egy alkalmazás ára két dologból áll össze: hány szakértői óra kell hozzá, és mennyibe kerül egy óra. Az óradíj a kiszámíthatóbb rész. A hazai piacon egy tapasztalt, terméktervezéssel is foglalkozó csapat óradíja jellemzően 18 és 30 ezer forint között mozog, egy nyugat-európai ügynökségé ennek a többszöröse. Az órák száma viszont egy kétmondatos brief alapján száz és kétezer között bárhol lehet, és ez adja ezt az óriási szórást az ajánlatok között.

Ezért nem kapsz komoly csapattól árat egy „olyan kéne, mint a Wolt, csak kutyakajára" leírásra. Amit kapsz, az egy rövid, fizetős felfedező szakasz (discovery), ahol közösen leírjuk, ki használja majd, mire, milyen adatokkal, és mi történik, ha valami félremegy. Ennek a végén már van értelme számot mondani. Ha egy ügynökség enélkül ad fix árat, vagy alaposan túlárazta, hogy biztosan beleférjen, vagy menet közben fogja kiszámlázni a különbséget módosítási igény címén.

Egy kérdést érdemes még az elején tisztázni: tényleg mobilalkalmazás kell, vagy egy böngészőben futó webalkalmazás is megoldja? Az utóbbi sokszor gyorsabb és olcsóbb, és nem kell az áruházakon (app store-ok) keresztül terjeszteni. Erről a döntésről külön írtunk: weboldal vagy webalkalmazás, mi a különbség.

A négy tényező, ami az árat mozgatja

Ha az ajánlatok között nagy a szórás, szinte mindig e négy dolog egyikében gondolkodnak másképp a felek. Érdemes mindre külön rákérdezni.

1. Funkciók száma és bonyolultsága

Ez a legnagyobb tétel. Egy regisztráció, egy lista, egy részletező képernyő és egy űrlap még egyszerű. Push értesítés, fizetés, chat, térkép, offline mód, több felhasználói szerepkör: mindegyik plusz képernyő, plusz háttérlogika és plusz hibalehetőség, amit tesztelni kell. A funkciók költsége nem összeadódik, hanem majdhogynem szorzódik, mert az újaknak a régiekkel is együtt kell működniük.

2. Platformok: web, iOS, Android

Natív fejlesztésnél két külön alkalmazás készül (Swift iOS-re, Kotlin Androidra), ami közel duplázza a fejlesztési és a karbantartási költséget. Cross-platform technológiával (React Native, Flutter) egy kódbázisból készül mindkét app, ez jellemzően 30-40 százalékkal olcsóbb a natívnál, és a legtöbb üzleti alkalmazásnál a felhasználó nem érzi a különbséget. A webalkalmazás a legolcsóbb út, ha nincs szükség hardverközeli funkcióra.

Natívra akkor van szükség, ha a teljesítmény vagy a hardver központi: kameraintenzív képfeldolgozás, komoly animáció, háttérben futó szolgáltatások, Bluetooth-eszközök. Ha egy ügynökség ilyen indok nélkül is két külön natív appot javasol, kérdezd meg, miért.

3. A tervezés mélysége

A UX/UI tervezés a teljes költség 15-25 százaléka szokott lenni, és ezen a legrosszabb spórolni. A tervezési szakaszban derül ki, hogy a folyamat, amit le akarsz programoztatni, működik-e egyáltalán a felhasználó fejében. Egy rossz képernyőt átrajzolni egy nap, lefejlesztve újraírni akár hetek is lehet (még AI-supportal is, hiszen sokszor ez magával ránt egyéb módosításokat is; pl.: adatbázis, felhő tárhely, stb...). Arról, hogy mi mehet félre és mit veszíthetsz, ha ezt a szakaszt meg szeretnéd spórolni, külön cikkünk szól: miért bukik el egy app a rossz UX-en. A lényeg röviden: házat sem kezdesz el építeni tervrajzok nélkül és szerintem ezzel mindent el is mondtunk a UX tervezés fontosságáról.

4. Integrációk

Fizetés (Stripe, Barion, SimplePay), számlázó (Számlázz.hu, Billingo), CRM (HubSpot), meglévő vállalati rendszer, külső API. Minden bekötés külön fejlesztés, külön tesztelés és külön hibaforrás, mert a másik oldalon lévő rendszer is változik. Egy-egy jól dokumentált szolgáltatás bekötése a hazai piacon jellemzően 300 ezer és 1,5 millió forint közötti tétel, egy rosszul dokumentált belső rendszeré ennek a többszöröse is lehet.

Reális ársávok a hazai piacon

Amikor valaki azt kérdezi tőlünk, mennyibe kerül egy app, ezekkel a sávokkal válaszolunk. A saját projektjeinkből és a hazai ügynökségi piacról jönnek, egy platformra, cross-platform vagy webes technológiával számolva. Natív, két platformra: szorozd meg őket 1,6 és 1,8 közötti értékkel.

• Kattintható prototípus, fejlesztés nélkül: 500 ezer és 1,5 millió forint között. Erre lehet befektetőt vagy első ügyfelet szerezni, és ezzel lehet a legolcsóbban kideríteni, hogy egyáltalán kell-e valakinek.
• MVP, egy platform, 3-5 alapfunkció: 4-10 millió forint. Regisztráció, egy fő folyamat, egyszerű admin. Ezzel lehet piacra lépni és valós visszajelzést gyűjteni.
• Közepes üzleti app: 10-25 millió forint. Felhasználói szerepkörök, fizetés, értesítések, riportok, két-három integráció.
• Komplex rendszer: 25 millió felett, nyitott felső határral. Valós idejű adatok, egyedi algoritmus, hardverkapcsolat, több piacra szabott logika.

Ha az ajánlat ezeknél jóval alacsonyabb, kérdezd meg, mi nincs benne. A tesztelés, a tervezés, az áruházi beadás és a bevezetés utáni javítások a gyakori hiányzók. Az MVP-fejlesztésről szóló cikkünkben részletesen leírtuk, hogyan lehet a scope-ot úgy meghúzni, hogy az első verzió a legalsó sávban maradjon.

Mennyibe kerül az app azután, hogy elkészült?

Az elkészült app a legtöbb ajánlatban egyetlen szám, pedig a költség egy jelentős része a bevezetés után jön. Ezekkel számolj az első évtől:

• Karbantartás és frissítések: az eredeti fejlesztési költség évi 15-20 százaléka. Új iOS- és Android-verziók, könyvtárfrissítések, apró hibák, biztonsági javítások.
• Szerver és infrastruktúra: egy kisebb app felhős háttere havi 15-40 ezer forint, egy nagy forgalmú, sok adatot mozgató rendszeré havi százezer felett.
• Áruházi díjak: az Apple fejlesztői programja évi 99 dollár, a Google Play egyszeri 25 dollár. Az alkalmazáson belüli vásárlások és előfizetések után 15-30 százalék jutalékot vonnak le.
• Külső szolgáltatások: térkép, SMS, e-mail, fizetési kapu, analitika. Egyenként kicsi tételek, együtt havi tízezrektől százezrekig.
• GTM, azaz Go to Market költségek, magyarul hívjuk csak Marketing költségeknek: a legjobb appra sem talál rá senki magától. Az áruházi optimalizálás és a hirdetés külön büdzsé, ami induláskor nem ritkán vetekszik a fejlesztés árával.

Ha mindezt összeadod, egy 8 milliós MVP első két éve reálisan 11-13 millió forint a marketing nélkül. Ez nem rossz hír, csak számolni kell vele az elején, és nem a harmadik hónapban meglepődni rajta.

Hogyan tartsd kézben a költségeket?

A túlköltések nagy része a scope-ban keletkezik, a fejlesztőknél csak látszik. Ez az öt lépés a tapasztalatunk szerint a legtöbbet spórolja.

• Validáld az ötletet, mielőtt fejlesztenél. Interjúk, landing oldal, előregisztráció: pár százezer forintból kiderül, hogy a piac akarja-e. Erről szól a mobilalkalmazás-ötlet validálásáról szóló útmutatónk.
• Kezdd egy platformon és egyetlen fő folyamattal. A második platform és a „jó lenne még" funkciók akkor jönnek, amikor az első verzió már használatban van.
• Fizess a tervezésért külön. Egy kattintható prototípus után sokkal pontosabb ajánlatot kapsz, és ha mégsem építed meg, nem vesztettél milliókat.
• Kérj tételes ajánlatot: tervezés, fejlesztés, tesztelés, áruházi beadás és bevezetés utáni támogatás külön sorban. Ami nincs benne, azt utólag fogod kifizetni.
• Tervezd be az üzemeltetést a nulladik naptól. Ki javít, ha leáll, mennyi idő alatt, és mennyiért.

Nálunk minden ilyen projekt terméktervezéssel indul, és a fejlesztési ajánlat csak ezután készül el. Így dolgoztunk a Krewly, a Nimitz és a Bubbles digitális termékén is: először a folyamat és a képernyők, utána a kód. Ez a sorrend az, ami miatt az ajánlat a végén stimmel a számlával.

Kérj ajánlatot úgy, hogy össze is tudd hasonlítani

Ha van egy app-ötleted, ne képernyőket sorolj a levélben. Írd le, ki használná, milyen folyamatot váltana ki, és mi történik ma enélkül. Ebből mi meg tudjuk mondani, hogy webalkalmazás vagy mobilapp kell-e, melyik ársávban mozog, és mit érdemes az első verzióból kihagyni. A mobilalkalmazás-fejlesztés oldalunkon leírtuk, hogyan dolgozunk, a UX/UI tervezés oldalon pedig azt, hogy miért ezzel kezdjük. Ha inkább beszélnél róla, írj nekünk, és egy órában végigmegyünk rajta.