Mennyibe kerül valójában egy egyedi mobilapp fejlesztése

Aki rákeres a „mobilapp fejlesztés ára” kifejezésre, egyetlen cikken belül is akár tízszeres szórást lát ugyanarra a kérdésre. Ez nem tisztességtelenség — egyszerűen abból fakad, hogy egy hétvégi prototípust és egy banki alkalmazást ugyanaz a szó, „mobilapp”, takar. A kettőnek szinte semmi köze egymáshoz azon kívül, hogy telefonon fut.

Flutterben fejlesztünk, mert egyetlen kódbázisból iOS-re és Androidra is kiadni valós hatékonyságnövelés — nem csak marketingszöveg. De a keretrendszer sosem volt az a tényező, ami a projekt árát valójában megemeli. Íme, mi az.

A funkciólista maga a becslés

Egy Flutter-app, ami egy étlapot mutat és rendelést vesz fel, szinte semmiben nem hasonlít egy Flutter-appra, ami offline szinkronizál, push értesítéseket kezel, alkalmazáson belüli vásárlást bonyolít és háttérben helyzetet követ. Mindkettő ugyanabból a keretrendszerből fordul, de az egyik töredéknyi mérnöki munkát igényel a másikhoz képest.

Ezért minden szám, amit „mobilapp” mellé látsz funkciólista nélkül, valójában csak egy helykitöltő. A becsülhető kiindulópont ugyanaz, mint egyedi szoftvereknél: le kell írni a képernyőket, milyen adatra van szükség offline állapotban, mi történik kapcsolat nélkül, és ki fogja használni — utána a becslésnek van mire támaszkodnia.

Ami valóban mérnöki időt igényel

Offline működés. Egy app, ami csak élő kapcsolattal működik, egyszerűbb, mint egy, aminek helyben és szerveren tárolt állapotot kell összeegyeztetnie. Ha a felhasználók néha jel nélküli helyen vannak — raktárban, kompon, vidéki rendelőben —, az offline kezelés nem utólagos csín, hanem az alapfeladat része.

Store-mechanika. Az áruházi lista, a képernyőképek és a review-folyamat nem utógondolat; az Apple és a Google is elutasít appokat olyan okokból, aminek semmi köze a kódhoz. Egy elutasítás-és-újrabeadás ciklusra időt szánni reális tervezés, nem pesszimizmus.

Fizetések. Az alkalmazáson belüli vásárlásokat és előfizetéseket egy dedikált fizetéskezelő rétegen keresztül vezetjük, amely a nyugtaellenőrzést és a jogosultságkezelést végzi — ezeket a platform-API-k szükségtelenül fájdalmassá teszik önállóan megírva. Ez időt spórol a saját megoldáshoz képest, de a vásárlási folyamat megtervezésének szükségességét nem szünteti meg.

Meglévő app átvétele. Valaki más Flutter-kódbázisának auditálása és folytatása bármelyik irányba mozdíthatja az árat: egy tiszta, tesztelt kódbázist gyorsabb bővíteni, mint nulláról kezdeni; egy dokumentálatlant, állapotkezelési minta nélkül, drágább lehet megérteni, mint újraírni.

Amit sokan kihagynak a becslésből

Push értesítések rendszere. Egy egyszerű “új rendelés érkezett” push más terjedelem, mint egy értesítési rendszer, amely felhasználói preferenciákat, csendes órákat és csoportosított értesítéseket kezel, hogy ne bombázza a felhasználót minden apró eseménnyel. Ez utóbbi saját backend-logikát igényel, nem csak egy platform-API hívást.

Lokalizáció. Egy app, ami csak magyarul fut, egyszerűbb, mint egy, ami több nyelven és több pénznemben kezeli a tartalmat. Nem csak a szövegek fordításáról van szó — a hosszabb szövegek elronthatják a képernyőelrendezést, és minden nyelvhez saját tesztelési kör tartozik.

Analitika és hibajelentés. Egy app, amit senki nem figyel élesben, könnyű döntéseket hoz vakon: melyik képernyőn hagyják abba a felhasználók, milyen hibák futnak crash-be éles környezetben. Ennek beépítése az induláskor sokkal olcsóbb, mint utólag rájönni, hogy fogalmunk sincs, mi történik a felhasználóknál.

Hol ül valójában a költség

Tényező	Alacsony komplexitás	Magas komplexitás
Kapcsolat	Mindig online	Offline-first, szinkronizálással
Képernyők	10 alatt	20+, beágyazott navigációval
Platform-integrációk	Csak push	Kamera, Bluetooth, háttér-helyzet
Fizetés	Nincs vagy egyszeri	Előfizetés, több csomaggal
Backend	Meglévő API	Új API az apppal párhuzamosan

Egy app bárhol elhelyezkedhet ezen a táblázaton, és a helye — nem a „Flutter” szó — az, amit egy valódi ajánlat tükröz.

Amit a keretrendszer megváltoztat, és amit nem

Az egy kódbázis mindkét platformra valóban csökkenti az iOS és Android közötti funkcióparitás mérnöki költségét — nem építesz és tartasz karban két külön implementációt ugyanarra a logikára. Ez valós megtakarítás, és az app életciklusa alatt halmozódik: minden jövőbeli funkciót egyszer építesz meg, nem kétszer.

Amit nem változtat meg, az az áruházi oldal. Az Apple review-folyamata, a Google Play szabályai, a képernyőkép-követelmények ugyanazok, függetlenül attól, milyen keretrendszerből származik a bináris. Aki „Flutter app” árat ad anélkül, hogy sorba venné a store-beadást és a review-ciklust, hiányos projektet áraz.

Backend munkát sem szüntet meg. Egy Flutter-app, aminek felhasználói fiókra, adatszinkronra vagy szerveroldali logikára van szüksége, backendet igényel — ez egy egyedi szoftver projekt az app mellett futva, saját költségtényezőkkel. Ha azon gondolkodsz, hogy egy meglévő rendszert vegyél át vagy egyedit építtess a backend oldalon is, arról külön írunk.

Hogyan mérjük fel valójában

A mobilapp fejlesztéshez ugyanúgy állunk hozzá, mint bármely egyedi szoftverprojekthez: írott specifikáció a szám előtt, iteratív szállítás, hogy valódi build-eket tesztelsz valódi eszközökön kéthetente, nem makettet nézel, és egyértelmű pont arról, hogy ki birtokolja a kódot és az áruházi listákat, amikor élesedik. Egy app, aminek App Store Connect és Google Play fiókjait nem te birtoklod, olyan app, amit nem tudsz frissíteni anélkül, hogy visszamennél ahhoz, aki beállította — érdemes ezt tisztázni aláírás előtt, függetlenül attól, ki fejleszti.

Ez az utolsó pont könnyen kimarad az ajánlatból, és drágán derül ki utólag. Ha egy fejlesztő „kényelemből” a saját szervezete alatt tartja a store-fiókokat, minden jövőbeli frissítés, minden hibajelentés-válasz rajta keresztül fut. Kérd, hogy a fiókok induláskor a te nevedre kerüljenek át, írásban, az első számla előtt.

Ha azon gondolkodsz, natívan, cross-platformon vagy egy meglévő app átvételével építkezz, ez pontosan az a kérdés, amit egy rövid beszélgetés gyorsabban megválaszol, mint egy újabb összehasonlító cikk. Saját termékeink, amelyek a referenciák oldalon szerepelnek, ugyanígy épülnek: egy kódbázis, rendezett store-mechanika, forráskód, ami a tiéd, amikor kész.

A keretrendszer dönti el, hányszor kell megépíteni egy funkciót. Minden más a listán azt dönti el, mennyi ideig tart egyszer megépíteni.

Ha már van funkciólistád, egy kapcsolatfelvételi űrlap gyorsabban ad valódi becslést, mint egy újabb keresés.