Miért nem egyszerű a freelancer vagy ügynökség kérdés
A legtöbb vállalkozó árkérdésként teszi fel: “mennyivel drágább egy ügynökség?”
Rossz kérdés.
A helyes kérdés az, hogy a te projekted mennyi különböző szakmai szerepkört igényel egyszerre.
Egy háromképernyős időpontfoglaló app és egy fizetési integrációval, admin felülettel és push értesítésekkel működő piactér nem ugyanaz a feladat.
Az első egy ember három hete.
A második öt szakma párhuzamos munkája.
A döntést valójában négy paraméter határozza meg: a képernyők száma, a felhasználói szerepkörök mennyisége, a backend fejlesztés összetettsége és a külső integrációk (fizetés, térkép, CRM, ERP) darabszáma.
Ezek után jön az ár.
És itt jön a második tévhit.
A piacon nem két modell létezik, hanem három.
A legtöbb megrendelő csak a freelancert és a klasszikus ügynökséget ismeri, pedig az elmúlt években megjelent egy harmadik forma: a senior-led product studio. Egyetlen tapasztalt szakember, aki ügynökségi lefedettséggel dolgozik, de freelancer sebességgel és árszinten.
Ez a cikk nem elvi előny-hátrány listát ad.
Kapsz egy konkrét döntési mátrixot küszöbértékekkel, egy költséglistát a fejlesztési díjon túli tételekről, és egy szerződéses ellenőrzőlistát, amit az első konzultáción elővehetsz.
A rossz modellválasztás nem pénzben, hanem elvesztegetett hónapokban fáj a legjobban. Egy leállt projekt újraindítása jellemzően a teljes költségvetés 40-60 százalékát viszi el.
A három fejlesztési modell
Mindhárom modell működik.
A kérdés csak az, melyik illik ahhoz, amit építeni akarsz, és mekkora kockázatot bírsz el.
Freelancer
Egy ember tervez, kódol, tesztel és publikál.
Az induló ár a legalacsonyabb a piacon, mert nincs mögötte iroda, projektmenedzser vagy értékesítő, akinek a bérét be kellene árazni.
A kommunikáció közvetlen: írsz neki, ő válaszol.
Nincs három lépcsős egyeztetés, nincs “megkérdezem a csapatot”.
A gyengeség viszont strukturális.
Nincs társtervező, aki átnézi a UX/UI tervezést, nincs független tesztelő, aki megtalálja a saját vakfoltjait, és nincs helyettesítő fejlesztő, ha lebetegszik vagy jön egy jobban fizető megbízás.
Sok freelancer emellett egy technológiában erős.
Ha kiváló Flutter-fejlesztő, de a backend fejlesztés nem az erőssége, akkor vagy alvállalkozót hoz (akit te nem ismersz), vagy kompromisszumot köt az architektúrában.
Klasszikus ügynökség
Itt minden szerepkör külön ember: projektmenedzser, UX designer, UI designer, backend- és frontend-fejlesztő, QA tesztelő.
Papíron ez a legteljesebb lefedettség.
A gyakorlatban az ügynökségi modell két költséget hoz magával, amit ritkán mondanak ki hangosan.
Az egyik az overhead: iroda, sales, adminisztráció, üresjáratban álló kapacitás. A másik a kommunikációs veszteség.
Minden információ, amit elmondasz, legalább két emberen megy át, mire a kódig ér. Az üzleti szándékodból lesz egy brief, a briefből egy ticket, a ticketből egy funkció.
Minden áthaladásnál veszít a jelentéséből.
Az ügynökségek emellett hajlamosak a legdrágább embert a tárgyalóba küldeni, a legolcsóbbat pedig a kódhoz ültetni. Ez nem szükségszerű, de elég gyakori ahhoz, hogy rá kelljen kérdezni: ki fogja ténylegesen írni a kódot?
Cserébe: valódi minőségbiztosítás és QA tesztelés, dokumentált projektmenedzsment, és a bus factor problémája megoldva.
Ha egy fejlesztő kiesik, más átveszi.
Senior-led product studio
A harmadik modell arra a felismerésre épül, hogy az ügynökségi overhead nagy része nem érték, hanem koordináció. Ha egyetlen tapasztalt szakember végigviszi a folyamatot a validációtól a publikálásig, a koordinációs költség eltűnik.
Ez korábban nem volt reális.
Egy ember nem tudott ügynökségi minőségű designt, backendet és tesztelést szállítani észszerű idő alatt.
2026-ra viszont az AI-támogatott fejlesztői eszközök, a kész backend-platformok (Firebase, Supabase) és az érett cross-platform fejlesztés keretrendszerei megsokszorozták egy senior fejlesztő kapacitását.
A studio-modell így ügynökségi lefedettséget ad freelancer-szintű rugalmassággal.
Egy kontaktszemély, egy felelős, nulla információvesztés a lépcsőfokok között.
A CompletApp ebbe a harmadik kategóriába tartozik: fix áras fejlesztés, mérföldkövekre bontott folyamat, kiszállási garanciával védve. A tervezés, a kód és az élesítés nem vándorol csapatok között, mert nincsenek csapatok, amik között vándorolhatna.
Melyik modell illik a projektedhez?
Az alábbi küszöbértékek nem elméletiek.
Több száz magyar mobilalkalmazás-fejlesztési projekt tapasztalata mögöttük van, és meglepően jól előrejelzik, hol borul fel egy vállalás.
Képernyők, szerepkörök és backend komplexitás
A gyakorlati határvonal a 3-5 képernyőnél és az egy felhasználói szerepkörnél húzódik. Ekkora MVP fejlesztés vagy proof of concept egy jó freelancerrel is biztonságosan elkészül.
10 képernyő felett, két vagy több szerepkörrel (például felhasználó és admin), külső fizetési integrációval már más a helyzet. Itt egyszerre kell UX-döntéseket hozni, adatmodellt tervezni, jogosultságokat kezelni és tesztelni.
Egy ember számára ez nem kapacitáskérdés, hanem figyelemkérdés.
Fontos tisztázni, mi az MVP.
Nem félkész termék, nem “majd később megcsináljuk rendesen” verzió.
Az MVP a legkisebb olyan működő kiadás, amivel validálható az üzleti feltevés, és amit egy valódi felhasználó valódi pénzért használna.
Ez azért befolyásolja a modellválasztást, mert a “gyorsan összedobjuk” mentalitás pontosan azt a minőséget adja, ami miatt az áruházi értékelés 2 csillag lesz, és a validáció eredménye értelmezhetetlen.
A bus factor kockázata egyetlen freelancernél
A bus factor az a szám, hogy hány embernek kell kiesnie a projektből ahhoz, hogy az leálljon.
Freelancernél ez a szám: egy.
Nem kell drámai eseményre gondolni.
Elég, ha jön egy hosszabb betegség, egy jobban fizető ügyfél, egy költözés vagy egy kiégés.
A kód ott marad félkészen, dokumentáció nélkül, olyan architektúrával, amit csak ő értett.
A konkrét kár általában három rétegű: a határidő csúszik 2-4 hónapot, az új fejlesztő 20-40 százalékos felárral veszi át az idegen kódot, és a funkciók egy része újraírásra kerül.
Ez a legdrágább hiba a mobilalkalmazás-fejlesztésben.
| Szempont | Freelancer | Klasszikus ügynökség | Senior-led product studio |
|---|---|---|---|
| Költség (10 képernyős app) | Legalacsonyabb, jellemzően 1,5-3,5 M Ft | Legmagasabb, 8-25 M Ft | Középső sáv, 3-8 M Ft |
| Sebesség indulásig | 1-2 hét, azonnali start | 4-8 hét felmérés és szerződés után | 1-3 hét, brief után azonnal |
| Kontroll és kommunikáció | Közvetlen, de kiszámíthatatlan elérhetőség | Strukturált, de 3-5 fős lánc | Közvetlen, egy felelős szakember |
| Skálázhatóság | Gyenge: egy ember kapacitása a plafon | Erős: csapat bővíthető | Közepes-erős: partnerhálózat bevonható |
| Szakmai lefedettség (UX/UI, backend, QA) | Részleges, jellemzően 1-2 erős terület | Teljes, külön szerepkörökben | Teljes, egy kézben tartva |
| Bus factor / üzleti kockázat | 1 (magas kockázat) | 3+ (alacsony kockázat) | 1 fő + szerződéses kiszállási garancia |
| Ideális projektméret | 3-5 képernyő, 1 szerepkör, 0-1 integráció | 25+ képernyő, 3+ szerepkör, vállalati rendszerek | 8-25 képernyő, 2-3 szerepkör, fizetés és API |
A táblázatból egy dolog látszik élesen: nincs univerzálisan jó válasz. Van projekt, ahol az ügynökség pénzkidobás, és van, ahol a freelancer felelőtlenség.
A fejlesztési díjon túli költségek
A legtöbb árajánlat egyetlen számot mutat.
Ez a szám az esetek többségében a teljes első éves költség 60-75 százaléka.
A maradék nem eltitkolt trükk, hanem olyan tétel, amire senki nem kérdez rá időben.
Íme a teljes lista.
Egyszeri, a fejlesztéshez kapcsolódó tételek:
- Projektmenedzsment: ügynökségeknél jellemzően a fejlesztési díj 10-20 százaléka, külön soron. Studio-modellben és freelancernél általában beépített, de érdemes írásban tisztázni.
- UX/UI tervezés: wireframe, kattintható prototípus, designrendszer. Egy 10-15 képernyős appnál ez önmagában 300 ezer és 1,5 millió forint közötti tétel, és nem opcionális, ha a felhasználók meg is akarják tartani az appot.
- Minőségbiztosítás és QA tesztelés: eszközfarm, regressziós tesztelés, hibajegy-kezelés. Sok ajánlatban ez a legelőször kihúzott sor, és a legelőször megbosszuló hiány.
- Áruházi publikálás: App Store és Google Play beküldés, store listing szövegek, screenshotok, adatvédelmi nyilatkozat, adatkezelési kérdőívek kitöltése. Az első beküldés elutasítása normális, az újrabeküldés viszont időt visz.
- Karbantartás és frissítés: évente legalább két OS-verzió jelenik meg iOS és Android oldalon. Ha nem követed, az app 12-18 hónap alatt eltörik. Reális éves keret a fejlesztési díj 15-20 százaléka.
Folyamatos üzemeltetési költségek:
- Felhő és backend: Firebase vagy Supabase induló szinten gyakran ingyenes, de néhány ezer aktív felhasználó felett havi 25-150 ezer forint közötti sávba kerül. A növekedés itt nem lineáris, hanem lépcsős.
- Analitika és hibakövetés: Firebase Analytics, Mixpanel, Sentry. Havi 0-40 ezer forint, de ezek nélkül vakon repülsz.
- Push notification szolgáltatás: alapszinten ingyenes, szegmentált kampányokhoz (OneSignal, Braze) havi 15-100 ezer forint.
- Előfizetés-kezelés: Stripe 1,4-2,9 százalék tranzakciónként, RevenueCat a bevétel 1 százaléka egy bizonyos árbevétel felett. Ehhez jön az Apple és Google 15-30 százalékos áruházi jutaléka.
- Fejlesztői fiókok: Apple Developer Program évi 99 USD, Google Play Console egyszeri 25 USD.
Szerződéses ellenőrzőlista (ezt kérd írásban, minden ajánlatnál):
- Forráskód-tulajdonjog: a kifizetés után a teljes forráskód a tiéd, korlátozás nélkül. Ha ez nincs leírva, jogilag nem a tiéd.
- Repository-hozzáférés: a fejlesztés alatt is legyen olvasási jogod a GitHub/GitLab repóhoz, ne csak az átadáskor.
- Harmadik féltől származó licencek: milyen fizetős könyvtárak, sablonok, ikonkészletek vannak beépítve, és kinek a nevén van a licenc.
- Adatkezelési felelősség: ki az adatkezelő és ki az adatfeldolgozó GDPR-értelemben, és van-e írásos adatfeldolgozói szerződés.
- Hibajavítási garancia: átadás után hány hónapig és milyen hibatípusokra terjed ki díjmentesen. A 3-6 hónapos garancia a piaci norma.
- Átadás-átvétel feltételei: mit jelent a “kész”: forráskód, dokumentáció, build utasítások, környezeti változók, publikált app.
Egy külön pont, amit ki kell emelni: az Apple és Google fejlesztői fiókot mindig a megrendelő hozza létre a saját nevén. Ha a fejlesztő fiókjában van az appod, akkor egy vitás helyzetben nem tudod áthelyezni, frissíteni, és a felhasználói értékelések sem a tieid.
A fiók átadása később bonyolult, néha lehetetlen.
Hogyan hasonlítsd össze két ajánlatot
Két árajánlat között a végösszeg a legkevésbé informatív adat. Két számot csak akkor lehet összehasonlítani, ha ugyanazt fedik le.
- Tedd fel a hat kulcskérdést az első konzultáción. Ki készíti a UX-et és van-e kattintható prototípus a kódolás előtt? Ki végzi a biztonsági felülvizsgálatot? Ki nyújtja be az appot az áruházba, és kinek a fiókjából? Fix áras vagy óradíjas fejlesztés? Ki írja ténylegesen a kódot? Mi történik, ha az adott ember kiesik?
- Egységesítsd a scope-ot mindkét ajánlatban. Kérd el képernyőnkénti bontásban, hogy mit tartalmaz. Ha az egyik ajánlat 12 képernyőt és admin felületet ad 6 millióért, a másik 8 képernyőt admin nélkül 4,5 millióért, akkor a második a drágább.
- Vesd össze a mérföldköveket és a fizetési ütemezést. Egy egészséges appfejlesztési brief alapján készült ajánlat 3-5 mérföldkövet tartalmaz, mindegyikhez konkrét, ellenőrizhető szállítmánnyal. Az 50 százalék előleg és 50 százalék végén konstrukció önmagában figyelmeztető jel.
- Hasonlítsd össze a támogatási szintet. Hány hónap garancia, milyen reakcióidővel, milyen csatornán? Az “igény szerint támogatunk” mondat nulla forint értékű.
- Keresd a vörös zászlókat. Nincs írásos scope-dokumentum. Nincs mérföldkő-bontás. A kódtulajdon nincs a szerződésben. Nincs helyettesítő vagy backup erőforrás. Az ajánlat 24 órán belül megérkezik érdemi kérdések nélkül. Bármelyik jelenléte esetén kérdezz vissza, kettő esetén lépj tovább.
- Döntsd el a cross-platform vs natív kérdést tudatosan. Ha iOS és Android egyszerre kell, a Flutter vagy React Native alapú cross-platform fejlesztés 30-40 százalékkal olcsóbb, mint két külön natív kódbázis. Natív iOS és Android fejlesztés ott indokolt, ahol nehéz grafika, komplex Bluetooth, AR vagy szélsőséges teljesítményigény van. A legtöbb üzleti app nem ilyen.
- Rögzítsd írásban a terjedelmet a scope creep ellen. A scope creep nem gonoszságból történik, hanem mert menet közben jó ötletek jönnek. Fix áras szerződésnél a leírt terjedelem védi mindkét felet: az új igény nem “belefér”, hanem külön változáskérelem, saját árral és határidővel.
A döntés, amit ma meg kell hoznod
A szabály egyszerű.
Ha egyszerű, kevés integrációt igénylő appra van szükséged gyorsan és olcsón, a freelancer valós, racionális választás.
Ha komplexebb termékről van szó, ahol a hosszú távú felelősség, a karbantartás és a felhasználói adatok biztonsága számít, akkor az ügynökség vagy a senior-led product studio a biztonságosabb út. A studio ebben a sávban általában jobb ár-érték arányt ad, mert nem fizeted meg a koordinációs overheadet.
De a modellválasztásnál is fontosabb valami más.
A scope creep és a bus factor ellen ugyanaz a három dolog véd, függetlenül attól, kit választasz: írásban rögzített terjedelem, fix ár, és mérföldkövekre bontott folyamat ellenőrizhető szállítmányokkal.
Ha ez a három megvan, egy freelancerrel is biztonságban vagy. Ha hiányzik, a legdrágább ügynökség sem ment meg.
Ennyi az egész.
