Hogyan Válassz Megbízható App Fejlesztő Céget?

Miért Csúszik El Ennyi App Projekt?

A legdrágább mobilalkalmazás nem az, amit túl sokért fejlesztettek le.

Hanem az, amit fél év után újra kell írni.

A rossz partnerválasztás költsége ritkán jelenik meg az első számlán. Előbb csúszik a határidő két hétttel, aztán hattal.

Majd kiderül, hogy a kódbázis nem dokumentált, a fejlesztő nem elérhető, és az új csapat első kérdése az, hogy „ezt inkább nulláról kezdjük”.

Ilyenkor a megrendelő kétszer fizet.

Egyszer a félkész termékért, egyszer a valódiért.

Az app fejlesztő cég kiválasztása témában a legtöbb magyar nyelvű cikk ugyanazt adja: egy általános szempontlistát referenciákról, kommunikációról és árról.

Ezek nem hibás szempontok.

Csak nem döntenek el semmit, mert nincs mögöttük pontozás, súlyozás és sorrend.

Ez az útmutató ezért egy döntési folyamatot ad, nem szempontfelsorolást.

Négy lépésben, abban a sorrendben, ahogy a valóságban is haladni kell.

A cél nem az, hogy megtaláld a legalacsonyabb árajánlatot.

A cél egy olyan termék, amit két év múlva is lehet karbantartani, továbbfejleszteni és átadni bárkinek.

Az egyedi app fejlesztés hosszú távú kötelezettség. A partner, akit most választasz, valószínűleg még a második és harmadik verziót is fejleszti majd.

Érdemes ennek megfelelő szigorral választani.

Építsd Fel az Összehasonlítható Briefet

A legtöbb ajánlatkérés két sorból áll: „Szeretnénk egy appot, mennyibe kerül?”

Az ilyen kérdésre kapott válaszok nem összehasonlíthatók, mert minden cég mást találgat ki a hiányzó információk helyére.

Az appfejlesztési brief nem bürokrácia.

Ez az egyetlen eszköz, amivel az ajánlatokat azonos alapra hozod.

Mit Küldj Minden Fejlesztőnek

Egy jó brief elfér két A4-es oldalon.

Nem specifikáció, hanem döntési keret.

Az alábbi pontokat mindenképpen tartalmazza:

• A projekt célja egy mondatban. Mit fog az app elérni üzletileg? Például: „a meglévő 4000 ügyfelünk önkiszolgáló módon tudjon időpontot módosítani, hogy csökkenjen a telefonos terhelés.” Ez irányítja a teljes UX/UI tervezést.
• A célcsoport és a használati helyzet. Kik használják, milyen eszközön, milyen körülmények között? Egy raktári alkalmazás felhasználói élménye teljesen más, mint egy fogyasztói fitnesz appé.
• A kulcsfunkciók listája prioritással. Sorolj fel 8 és 15 közötti funkciót, és jelöld meg, melyik kell az első verzióba. Ha mindegyik „must have”, akkor nem MVP fejlesztésről beszélünk, hanem egy sokkal nagyobb projektről.
• Platformok. iOS, Android, vagy mindkettő? Kell webes adminfelület? Ez a döntés a költség 30 százalékát is befolyásolhatja.
• Meglévő rendszerek. Van ERP, CRM, webshop vagy számlázórendszer, amivel integrálni kell? A backend és API-integráció szinte minden becslésben a legnagyobb bizonytalansági tényező.
• Kívánt határidő és annak oka. „Szeptemberre, mert akkor indul a szezon” használható információ. A „minél előbb” nem az.
• Becsült keret vagy keret-sáv. Igen, érdemes megadni. Nem azért, hogy oda igazítsák az árat, hanem hogy megmondják, mi valósítható meg belőle.
• Válaszhatáridő. Adj 7 vagy 10 munkanapot, és kérd, hogy addig jelezzenek, ha kérdésük van. Aki nem kérdez vissza, az valószínűleg nem is olvasta el.

Ugyanezt a dokumentumot küldd el mindenkinek, változtatás nélkül.

Ha az egyik cégnek több információt adsz, elveszíted az összehasonlítás lehetőségét.

A Súlyozott Pontozási Modell

Amikor megjönnek az ajánlatok, az emberi agy az árat fogja először megtalálni.

Ezért kell előre eldönteni, hogy mi mennyit számít.

Javasolt súlyozás egy tipikus mobilalkalmazás-fejlesztési projektnél:

• Scope-illeszkedés (25%). Az ajánlat pontosan azt tartalmazza, amit kértél, és a fejlesztő megkérdőjelezte, ami nem logikus? A legjobb partner néha lebeszél funkciókról.
• Referenciák (20%). Vannak élő, letölthető, hasonló komplexitású appjaik? Erről szól a következő fejezet részletesen.
• Technológiai illeszkedés (15%). A javasolt stack indokolt, vagy csak azt kínálják, amihez értenek?
• Kommunikáció (15%). Milyen gyorsan és milyen érthetően válaszolnak? Amilyen az ajánlatkérési fázis, olyan lesz a projekt.
• Ajánlat átláthatósága (15%). Látod a mérföldköveket, a szerepköröket, a tesztelési fázist és a projektmenedzsment költségét?
• Launch utáni támogatás (10%). Van írásos karbantartási és support folyamat, vagy „majd megbeszéljük”?

Pontozz minden jelöltet kategóriánként 1-től 5-ig, majd szorozd a súllyal.

A végeredmény gyakran meglepő: a legdrágább ajánlat nyer, mert egyedül az tartalmazza a QA-t és a dokumentációt.

Teszteld a Referenciákat és a Csapatot

A portfólió a legkönnyebben szépíthető része egy weboldalnak.

Egy Figma-mockup ugyanúgy néz ki egy screenshot-galériában, mint egy három éve élő, 50 ezer letöltéses alkalmazás.

A referencia-ellenőrzés ezért nem böngészés.

Ez nyomozás.

Portfólióscreenshot vagy Élő Termék?

Kérj minden referenciához App Store vagy Google Play linket.

Aztán nézd meg ezeket:

• Utolsó frissítés dátuma. Ha három éve nem jelent meg új verzió, az app valószínűleg nem él. Egy aktívan támogatott alkalmazás évente legalább 3-4 frissítést kap, már csak az OS-változások miatt is.
• Letöltésszám és értékelésszám. A Google Play mutatja a letöltési sávot. Ha 100 alatt van, az valószínűleg belsős vagy leállt projekt.
• Valós felhasználói vélemények. Olvass el 10 értékelést, főleg a 2 és 3 csillagosokat. Ezekből kiderül, hogy voltak-e krónikus összeomlások, lassulás vagy bejelentkezési problémák.
• A fejlesztő válaszai. Ha a fejlesztő vagy a megrendelő válaszol a negatív értékelésekre, az működő support folyamatra utal.
• Töltsd le és használd. Öt perc alatt kiderül, hogy az app teljesítménye rendben van-e: mennyi idő az indulás, akadozik-e a lista görgetése, mi történik gyenge hálózaton.

Kérdezz Rá a Backendre és Integrációkra

Egy szép felület nem bizonyíték semmire.

A projektek 80 százaléka a felület mögött csúszik el.

Ezért minden referenciánál kérdezz rá:

• Volt hozzá adminfelület? Egy webes admin, ahol a megrendelő maga kezeli a tartalmat, felhasználókat és riportokat, önmagában egy fél projekt.
• Több szerepkör volt a rendszerben? Ügyfél, munkatárs, vezető, adminisztrátor? A jogosultságkezelés komplexitása többszörözi a tesztelési igényt.
• Volt fizetési integráció? Stripe, SimplePay, Barion, in-app purchase? Ezek mindegyike külön szabályrendszerrel és külön hibakezeléssel jár.
• Volt valós idejű funkció? Chat, push értesítés, élő pozíciókövetés, azonnali szinkronizálás? Ez az egyik legnehezebben stabilizálható terület.
• Milyen külső rendszerhez kapcsolódott? Kérj konkrét példát arra, hogy egy meglévő vállalati API-hoz csatlakoztak, mert ott derül ki a valódi tapasztalat.

Az Első Konzultáció Kritikus Kérdései

A bemutatkozó hívás nem arról szól, hogy ők bemutatkoznak.

Arról, hogy te szűrsz.

• „Ki fogja konkrétan fejleszteni ezt a projektet, és beszélhetek vele?” Kérj nevet. Ha a sales-es nem tudja megnevezni a fejlesztőt, akkor a kapacitás valószínűleg még nem létezik.
• „Milyen arányban dolgoznak saját csapattal és alvállalkozókkal?” Az alvállalkozó nem eleve baj, de a felelősségi lánc hosszabb, és a tudás kikerül a cégből, amikor a szerződés lejár.
• „Melyik projektjük futott a legrosszabbul, és mit tanultak belőle?” Aki azt mondja, hogy minden projektjük sikeres volt, az vagy nem csinált eleget, vagy nem őszinte.
• „Hogyan látom majd a haladást hetente?” A jó válasz kattintható build vagy demókörnyezet. A gyenge válasz státuszriport Excelben.
• „Mi az, amit a briefemből kihúznának az első verzióból?” Egy tapasztalt partner erre azonnal tud válaszolni. Ez a kérdés szűri ki a legjobban a rutint.

Figyelmeztető jel, ha a cég nem tud megmutatni egyetlen élő terméket sem, amiben a saját csapata dolgozott.

És az is, ha minden kérdésre az a válasz, hogy „ezt majd a fejlesztés során tisztázzuk”.

Hasonlítsd Össze a Technológiát és az Ajánlatot

„Natívban fejlesztünk, mert az a legjobb.”

Ez a mondat 2026-ban már majdnem mindig eladási érv, nem műszaki döntés.

Natív vagy Cross-Platform?

A cross-platform fejlesztés egyetlen kódbázisból készít iOS és Android alkalmazást.

A Flutter esetében ez ma már natívhoz közeli teljesítményt és teljesen egyedi felületet is jelent, nem kompromisszumot.

A gyakorlati különbség nem a fejlesztési díjban látszik igazán, hanem a karbantartásban.

Két natív kódbázis esetén minden hibajavítást, minden új funkciót és minden OS-frissítést kétszer kell elvégezni.

A natív fejlesztés akkor indokolt, ha az app lényege maga a hardveres integráció: fejlett kamerakezelés, kiterjesztett valóság, óra-alkalmazás, alacsony szintű Bluetooth-protokoll.

Minden más esetben a cross-platform megoldás gyorsabb és fenntarthatóbb.

Fix Ár vagy Óradíj: Mit Rejt a Gyors Ajánlat

Ha 24 órán belül kapsz egy egysoros fix árat, az nem hatékonyság.

Az találgatás.

Egy komoly fix áras ajánlat mindig lebontott.

Konkrétan ezeket kell látnod benne:

• A képernyők száma és listája. „18 képernyő” ellenőrizhető állítás. „Teljes alkalmazás” nem az.
• A szerepkörök. Hány felhasználótípus, milyen jogosultságokkal?
• A backend és az API-k. Új backend készül, vagy meglévőhöz kapcsolódunk? Hány integráció?
• UX/UI tervezés külön sorban. Wireframe, kattintható prototípus, végleges design.
• Szoftvertesztelés. Kézi QA, automatizált tesztelés, eszközmátrix, hibajavítási kör.
• Projektmenedzsment. Ha nincs benne, valaki majd fizet érte, és az te leszel.
• App Store és Google Play publikálás. A store-előkészítés, adatvédelmi nyilatkozatok és review-folyamat kezelése is munka.
• Átadási dokumentáció. Architektúra-leírás, telepítési útmutató, API-dokumentáció.

Ami nincs benne írásban, az később change requestként jön vissza, gyakran a projekt legrosszabb pillanatában.

A gyakorlatban ez így néz ki: a CompletApp például írásos, mérföldkövekre bontott ajánlatot ad, heti kattintható előnézetekkel, és az első mérföldkő után fizetés nélküli kiszállási lehetőséget biztosít.

Ez a fajta struktúra a megrendelő kockázatát csökkenti, nem a fejlesztőét, és pontosan ezért érdemes hasonló feltételt kérni minden jelölttől.

Szerződés, Tulajdonjog és Launch Utáni Felelősség

Egy magyar középvállalat két évig nem tudta továbbfejleszteni a saját alkalmazását.

Az ok nem technikai volt.

A Google Play fejlesztői fiók a korábbi ügynökség nevén futott.

Ez a fejezet arról szól, hogy ez veled ne történhessen meg.

Mi Kerüljön az Átadásba

A forráskód-tulajdonjog nem elég, ha a kód körüli infrastruktúra nem a tiéd.

A szerződésnek nevesítve kell rögzítenie, hogy a teljes kifizetés után az alábbiak 100 százalékban a megrendelőhöz tartoznak:

• A forráskód repository. Teljes commit-történettel, nem egy zip fájlban. A történet nélküli kód átvehető, de sokkal nehezebben auditálható.
• A cloud- és szerverfiókok. AWS, Google Cloud, Firebase, Supabase vagy bármi más: a számlázás és a hozzáférés is a te nevedre kerüljön.
• Az App Store Connect és Google Play Console fejlesztői fiók. A saját céged nevén, a te bankkártyáddal. A fejlesztő kapjon meghívott hozzáférést, ne fordítva.
• A domainek és e-mail-szolgáltatások. Beleértve a push értesítési tanúsítványokat és aláíró kulcsokat.
• Az API-kulcsok és harmadik feles fiókok. Fizetési szolgáltató, térkép, SMS, e-mail, analitika.
• A teljes dokumentáció. Architektúra, adatbázis-séma, környezetek leírása, build- és deploy-folyamat, ismert hibák listája.
• A design-forrásfájlok. A Figma-projekt, ikonkészletek és licencelt betűtípusok jogi státusza.

A szellemi tulajdonjog átszállásának feltételét egy mondatban kell megfogalmazni: a végszámla kiegyenlítésével minden vagyoni jog korlátlanul, kizárólagosan és időben végtelenül a megrendelőt illeti.

GDPR és Biztonság a Gyakorlatban

A GDPR nem egy dokumentum, amit a végén hozzácsapunk.

Fejlesztési döntések sorozata, és privacy by design néven pontosan ez a szemlélet szerepel a szabályozásban is.

• Adatminimalizálás. Minden adatmezőnél legyen válasz arra, hogy miért kell. Ha a regisztrációhoz nem kell születési dátum, akkor ne is kérjük.
• Jogosultságkérések indoklása. A helyadat, kamera és névjegy hozzáférésnél a rendszer-párbeszéd előtt magyarázd el, mire kell. Ez a store-elfogadást is segíti.
• Analitikai SDK-k átláthatósága. Pontosan tudni kell, milyen third-party SDK-k futnak, mit gyűjtenek, és hova továbbítják. Az App Store adatvédelmi nyilatkozata ezt kötelezően kéri.
• Törlési folyamat. A fiók- és adattörlés az appon belülről elérhető legyen. A Google Play ezt 2023 óta követelményként kezeli.
• Hitelesítés módja. Jelszókezelés hash-eléssel, kétfaktoros lehetőség, biometrikus belépés, session-lejárat.
• Érzékeny adatok titkosított tárolása. Keychain iOS-en, Keystore Androidon. Token soha ne kerüljön egyszerű szövegként a helyi tárolóba.
• Hálózati kommunikáció védelme. Kizárólag TLS, kritikus esetben certificate pinning.
• Elvégzett biztonsági tesztelés. Kérdezd meg, dolgoztak-e már OWASP MASVS szerinti ellenőrzőlista alapján, és kapsz-e írásos eredményt.

Mit Vállaljon a Fejlesztő Indítás Után

A launch nem a projekt vége.

Statisztikailag ott kezdődik a munka nagyobbik fele.

• Hibajavítás garanciális időszakkal. Tipikusan 1-3 hónap, amiben a fejlesztési hibák javítása díjmentes. Rögzítsd, mi számít hibának és mi új funkciónak.
• OS-frissítések követése. Évente új iOS és Android major verzió jön. Ez kötelező munka, nem opció.
• Analitika és crash monitoring. Crashlytics vagy Sentry, plusz használati analitika. Cél a 99,5 százalék feletti crash-free session arány.
• Teljesítményfigyelés. Indulási idő, API-válaszidők, hibaarányok. Az app teljesítménye közvetlenül hat a megtartásra.
• Biztonsági javítások. Függőségek frissítése, sérülékenységek kezelése, tanúsítványok megújítása.
• Új funkciók fejlesztése valós adat alapján. A második verzió tartalmát ne a tárgyalóban döntsétek el, hanem abból, amit a felhasználók tényleg használnak.
• Reagálási idő szerződésben. Kritikus hiba esetén hány munkaóra? Elérhető-e a csapat a launch napján?

És végül a figyelmeztető jelek összegzése.

Homályos scope.

Kommunikáció, ami csak technológiákról szól, üzleti célokról nem.

Névtelen csapat, akiket soha nem látsz.

Dokumentáció nélküli átadás.

Bármelyik önmagában is elég ok arra, hogy tovább keress.

A Következő Lépés

Ha most csak egy ötleted van, ne kezdj el árakat gyűjteni.

Ülj le két órára, és írd meg az összehasonlítható briefet: cél, célcsoport, prioritásos funkciólista, platformok, meglévő rendszerek, határidő, keretsáv.

Ez a két óra a projekt legjobban megtérülő befektetése.

Ha már van két vagy három ajánlatod az asztalon, futtasd át őket a súlyozott modellen, mielőtt bármit aláírsz.

Az ár csak az egyik oszlop a hatból.

És egy konkrét teendő ma estére: írj e-mailt minden jelöltnek, és kérj olyan referenciát, ahol ténylegesen ők építették a backendet, az adminfelületet, és az alkalmazásnak valós, aktív felhasználói vannak.

A válaszok minősége önmagában el fogja dönteni a listát.