Mennyi Idő Kell Egy MVP Fejlesztéséhez Valójában?

Miért Hazudik Minden Egyetlen Számadat?

Ha rákeresel arra, hogy mennyi az MVP fejlesztési idő, három kattintás alatt kapsz négy egymásnak ellentmondó választ.

Négy hét. Nyolc hét. Három hónap.

Egyik sem mondja meg, mit mér.

Ez a legnagyobb probléma a legtöbb becsléssel: nem derül ki, hogy a megadott időtartam a puszta kódolást jelenti-e, vagy a teljes utat a kickofftól a publikált alkalmazásig. Egy stúdió „6 hetes MVP”-je könnyen lehet 10 hét, ha hozzáadod a discovery workshopot, a designjóváhagyást, a QA-t és az App Store review-t.

Az akadémiai kutatások is megerősítik, hogy az MVP-projektek kezdeti időbecslése kifejezetten megbízhatatlan. A minimum viable product definíciója szerint egy tanulási eszköz, amelynek pontos tartalma gyakran csak a discovery során kristályosodik ki, így a nulladik napon adott becslés természeténél fogva bizonytalan.

Egy becslés csak akkor hasznos, ha megmondod, mit tartalmaz és mekkora bizonytalanságot rejt. Minden más marketing.

Ez a cikk nem ad neked egy varázsszámot.

Ehelyett egy keretrendszert kapsz: fázisokra bontott időt, négy konkrét komplexitási kategóriát, a csúszás valódi okait és két hétre lebontott ütemtervet, amelyet össze tudsz vetni bármelyik ajánlattal, ami az asztalodon fekszik.

Mit Jelent Valójában a Fejlesztési Idő?

A fejlesztők általában a kódolási időt becslik meg. Az alapítók a naptárban gondolkodnak.

Ez a két szám ritkán egyezik, és a különbség szokta megölni a launch dátumot.

Fázisok Kickofftól Launchig

Egy komplett MVP-projekt hat jól elkülöníthető szakaszra bomlik. Ha bármelyik ajánlatban nem látod mind a hatot nevesítve, kérdezz rá, mert valamelyik ki lett hagyva a becslésből.

• Discovery és scope-véglegesítés (1-2 hét): discovery workshop, user story mapping, a core felhasználói folyamat feltérképezése és a funkciólista rögzítése. Itt dől el, mi kerül bele az MVP scope-ba és mi marad a version 2-re.
• UX/UI tervezés (1-2 hét): wireframe-ek, képernyőtervek, designrendszer és a felhasználói folyamat vizuális validálása. Egy 12-18 képernyős app designja ritkán készül el 5 munkanap alatt, ha egyedi vizuális nyelvet is kell építeni.
• Fejlesztés (2-12 hét): frontend, backend és API-integráció, adatmodell, jogosultságok, adminfelület. Ez a leghosszabb blokk, és itt szokás alábecsülni az integrációkat.
• QA és bugfix (0,5-2 hét): funkcionális tesztelés, QA és regressziós tesztelés eszközönként, hibalista és javítási körök. Egy második eszközkategória (tablet, alacsony felbontású Android) önmagában napokat ad hozzá.
• Zárt béta (1-2 hét): TestFlight vagy Google Play zárt teszt, 10-50 valós felhasználó, visszajelzés-gyűjtés és a kritikus hibák javítása. Ezt szinte minden ajánlatból kifelejtik.
• Áruházi publikáció (2 nap - 2 hét): store listing, screenshotok, adatvédelmi nyilatkozat, adatbiztonsági űrlap kitöltése és a review folyamat.

A publikáció ideje 2026-ban a legtöbb esetben gyors. Az App Store review átlagosan 24-48 óra alatt lefut, a Google Play néhány óra és néhány nap között végez, de az első beadásnál mindkét platformon hosszabb átfutásra érdemes számolni.

Elutasítás esetén viszont plusz egy hetet tervezz: javítás, újrabeadás, újabb sorbaállás. Ha a fejlesztői fiók még nem létezik, az Apple Developer Program regisztrációja és a cégazonosítás (D-U-N-S szám) önmagában 1-2 hetet is elvihet.

Miért Több, Mint a Kódolás

A kódolás körüli munka általában 30-50%-kal növeli a teljes projektidőt a nettó fejlesztési időhöz képest.

Ez nem pazarlás, hanem a projekt szerkezete.

• Döntési körök: minden design- és funkciójóváhagyás egy naptári kör, ami az ügyfél válaszidejétől függ, nem a fejlesztőétől.
• Tartalom-előkészítés: szövegek, termékleírások, kategóriák, jogi tartalom (ÁSZF, adatvédelmi tájékoztató), képek és logók. A hiányzó tartalom miatt megállt projekt gyakoribb, mint a technikai blokkoló.
• Harmadik feles fiókok: Stripe-verifikáció, banki adatok, push notification tanúsítványok, Google Cloud projekt beállítása. Ezekhez az ügyfél hozzáférése kell.
• Tesztelési ciklusok: a hibalista átnézése és visszaigazolása kétoldalú munka, nem egy fejlesztő magánügye.

Ha valaki „4 hetes MVP-t” ígér, tedd fel a kérdést: ebbe belefér a discovery, a design, a béta és a store review? Ha igen, akkor a scope-nak nagyon szűknek és nagyon fixnek kell lennie.

Komplexitási Kategóriák és Időbecslés

A hetek száma önmagában semmit nem mond.

A használható becslés bemenete négy változó: hány képernyő, hány felhasználói szerepkör, hány külső integráció és hány platform.

Az alábbi négy kategória lefedi az MVP-projektek nagyjából 90%-át. Keresd meg, melyikbe esik a te ötleted, és onnan indulj.

Egy gyors ökölszabály a saját becsléshez: képernyők száma × 0,5 nap (design + implementáció) + integrációnként 3-5 nap + szerepkörönként 2-4 nap jogosultságkezelésre, majd az eredményre tegyél 25-30% kockázati tartalékot.

Ez a tartalék nem opcionális.

A kutatások szerint az MVP-becslések hibaaránya éppen azért magas, mert a csapatok az ideális esetet kalkulálják, nem a valóságot, ahol egy Stripe-verifikáció három napig áll.

Mi Húzza Meg Leginkább a Határidőt?

A projektek nem attól csúsznak, hogy a fejlesztő lassan gépel.

Attól csúsznak, hogy a scope mozog, a döntések késnek, és valaki azt hitte, a cross-platform automatikusan feleannyi munka.

Scope Creep Konkrét Jelei

A scope creep ritkán érkezik nagy bejelentéssel. Apró, ésszerűnek hangzó kérésekben jön, amelyek egyenként két napnak tűnnek, együtt viszont hat hét.

• Új felhasználói szerepkör félúton: „legyen egy moderátor is”. Ez nem egy képernyő, hanem egy új jogosultsági réteg az adatbázisban, a backendben és minden érintett nézetben. Tipikusan +1-2 hét.
• Második platform bevétele: ha a projekt iOS-only indult és menet közben jön az Android (vagy fordítva), az nem csak build kérdése. Új tesztkör, új store-fiók, új eszközmátrix. +1-2 hét még Flutter esetén is.
• Chat funkció „csak még ez is”: valós idejű üzenetküldés olvasottsági állapottal, push-értesítéssel és moderációval minimum 1,5-3 hét. Az MVP-k egyik leggyakoribb rejtett bombája.
• Fizetés hozzáadása fejlesztés közben: Stripe vagy RevenueCat integráció, előfizetési logika, számlázás, próbaidőszak, visszatérítés. +2-3 hét, plusz a fiókverifikáció átfutása.
• Adminfelület bővítése:
• Adminfelület bővítése: az „egyszerű admin” gyakran válik teljes CMS-sé riportokkal és tömeges műveletekkel. Ez önálló termék, nem melléktermék.

A védekezés egyszerű, de fegyelmet kíván: minden új kérés a version 2 backlogba megy, nem az aktuális sprintbe. A MoSCoW módszer (Must have, Should have, Could have, Won’t have) pontosan erre való, és a „Won’t have” a legfontosabb oszlop benne.

Döntéshozatali Késedelmek

Ez a kevésbé látványos, de gyakran nagyobb tétel. A tapasztalat szerint az ügyféloldali visszajelzési kör átlagosan 7-10 nap, miközben a fejlesztő két nap alatt válaszol.

• Designjóváhagyás elhúzódása: a designt öt ember nézi át külön-külön, két hét telik el nulla fejlesztéssel. Egy döntéshozó kell, nem egy bizottság.
• Hiányzó tartalom: ha a termékleírások, kategóriák és jogi szövegek a fejlesztés végén érkeznek, a QA is akkor kezdődhet. Ez tipikusan 3-7 nap csúszás.
• Változó üzleti cél: ha a célközönség vagy az üzleti modell menet közben módosul, az a feature prioritás teljes újratárgyalását jelenti. Ilyenkor a discovery részben újraindul.
• Hozzáférések késése: Apple fiók, domain, Google Cloud projekt, banki adatok. Ezeket az első héten kérd be, ne a nyolcadikon.

Praktikus megoldás: rögzítsetek szerződésben egy maximális válaszidőt (48 óra) és nevezzetek meg egyetlen döntéshozót.

Ez a két mondat többet ér a határidő szempontjából, mint egy plusz fejlesztő.

Cross-Platform és AI Valósága

A cross-platform fejlesztés valóban gyorsít, de nem ott és nem annyit, ahogy a marketinganyagok sugallják. A Flutter egyetlen kódbázisból natív minőségű iOS és Android appot ad, és ez az UI-munkán reálisan 35-45%-ot spórol a két külön natív fejlesztéshez képest.

Amit viszont nem spórol meg: a platformspecifikus tesztelést és integrációt. Push notification (APNs vs. FCM), in-app purchase (App Store Connect vs. Google Play Billing), deep linking, engedélykezelés és háttérfolyamatok mindkét platformon külön beállítást és külön tesztkört igényelnek.

A Flutter a UI-t egyszerűsíti, nem az operációs rendszereket. A store-szabályok, a fizetési rendszerek és az értesítések továbbra is két külön világ.

Hasonló a helyzet az AI-jal. Egy OpenAI vagy Claude integráció jól definiált feladatra (szövegösszefoglalás, kategorizálás, strukturált kimenet) tényleg napok alatt működésbe hozható, ez 2026-ban már rutinmunka.

A hetek viszont ott mennek el, amit senki nem demózik: a kimenet validálása, a prompt injection elleni védelem, a rate limit és költségkontroll, a hibás vagy hallucinált válaszok kezelése és az edge case-ek.

Egy AI-funkció prototípusa két nap, egy éles, felhasználók kezébe adható AI-funkció két-három hét.

Így Néz Ki Egy Reális Ütemterv

Nézzük konkrétan.

Két modellt mutatok be, mérföldkövekkel és deliverable-ökkel, hogy össze tudd hasonlítani a saját projekteddel.

4 Hetes Fix Scope MVP

A négy hét reális, de csak három feltétel mellett: egyetlen fő felhasználói folyamat, előre jóváhagyott scope dokumentum, és 24-48 órán belüli ügyféldöntések.

Ha ebből bármelyik hiányzik, ez a modell nem működik.

1. Hét 1 - Scope zárás és designalap: discovery workshop, a core userflow rögzítése, képernyőlista véglegesítése és a wireframe-ek jóváhagyása. Deliverable: aláírt scope dokumentum és képernyőtérkép. Döntési pont: mi kerül a „Won’t have” listára.
2. Hét 2 - UI és fejlesztési alapok:
3. Hét 2 - UI és fejlesztési alapok: a designrendszer és a fő képernyők elkészülnek, párhuzamosan indul a projektváz, az auth és az adatmodell. Deliverable: kattintható prototípus és futó fejlesztői build. Döntési pont: végleges design jóváhagyása (48 órán belül).
4. Hét 3 - Core funkció implementáció: a teljes fő folyamat működik végponttól végpontig, backend és API-integrációval együtt. Deliverable: TestFlight vagy internal test build, amit már ki lehet próbálni. Döntési pont: funkcionális visszajelzés, kizárólag hibákra és nem új ötletekre.
5. Hét 4 - QA, store-előkészítés, launch: regressziós tesztelés eszközökön, hibajavítás, store listing, screenshotok, adatvédelmi dokumentáció és beadás. Deliverable: publikált app vagy review alatt lévő build.

Ez a modell akkor tartható, ha a szerződés is támogatja. A CompletApp például pontosan így dolgozik: előre rögzített fix scope és fix ár, mérföldkő-alapú átadás, és walk-away garancia, vagyis az első mérföldkő után az ügyfél fizetési kötelezettség nélkül kiléphet, ha nem elégedett.

A fix scope itt nem korlátozás, hanem a határidő technikai feltétele.

Nyitott funkciólista mellett négy hét matematikailag nem jön ki.

8-12 Hetes Komplexebb MVP

Ha fizetés, adminfelület, két platform vagy több szerepkör van a képben, a reális sáv 8-12 hét. Így oszlik el:

1. Hét 1-2 - Discovery és user story mapping: szerepkörök, jogosultságok, adatmodell és a teljes user story map felépítése, MoSCoW-prioritással. Deliverable: scope dokumentum, funkciólista és technikai architektúra vázlat.
2. Hét 3-4 - UX/UI tervezés: minden szerepkör folyamatának megtervezése, designrendszer, admin nézetek és üres/hibaállapotok. Deliverable: jóváhagyott, kattintható prototípus. Döntési pont: designfagyasztás, utána csak a version 2-be mennek a változtatások.
3. Hét 5-6 - Backend és core fejlesztés: auth, adatbázis, jogosultsági logika, API-k, alap adminfelület. Deliverable: működő backend és belső demo build.
4. Hét 7-8 - Fizetés, admin, iOS és Android: Stripe vagy RevenueCat integráció, előfizetési vagy tranzakciós logika, adminfunkciók befejezése, push notification mindkét platformon. Deliverable: feature-complete build. Döntési pont: mi marad ki a launch előtt.
5. Hét 9-10 - QA és zárt béta: regressziós tesztelés, eszközmátrix, 10-50 tesztfelhasználó bevonása TestFlighten és Google Play zárt tesztben, hibajavítási körök. Deliverable: hibalista, stabil release candidate.
6. Hét 11-12 - Store review és launch: store listing, adatbiztonsági űrlapok, adatvédelmi tájékoztató, beadás mindkét áruházba, elutasítás esetén javítás és újrabeadás. Deliverable: élő alkalmazás és launch utáni monitoring.

Egy fontos különbségtétel, ami a legtöbb cikkből hiányzik: a validációs MVP és a production-ready rendszer nem ugyanaz a projekt. Egy MVP célja, hogy 200-2000 felhasználón mérhető adatot adjon a piaci igényről.

Egy nagy terhelésre, összetett jogosultságokra, magas rendelkezésre állásra, auditálhatóságra vagy szigorú compliance-re (GDPR-adatfeldolgozási nyilvántartás, egészségügyi vagy pénzügyi szabályozás) felkészített rendszer 4-9 hónapos projekt. Ha ezt keresed, az MVP-ütemterv félrevezető lesz, és a time-to-market előnyt is elveszted, mert olyanra költesz, amit még nem validáltál.

Gyakran Ismételt Kérdések

Mennyi idő alatt lehet elkészíteni egy mobilalkalmazás MVP-jét?

Egy mobilalkalmazás MVP-je jellemzően 4-16 hét alatt készül el a kickofftól a publikálásig, a komplexitási kategóriától függően. Egyetlen fő felhasználói folyamattal és minimál authhal 4-6 hét, backenddel és adminfelülettel 6-10 hét, marketplace vagy kétoldalú platform esetén 10-16 hét.

A tartományt ne a hetek, hanem a képernyők, szerepkörök és integrációk száma alapján válaszd ki.

Mi befolyásolja leginkább az MVP fejlesztési idejét?

A legnagyobb hatása a scope stabilitásának és az ügyféloldali döntési sebességnek van, nem a technológiának.

A scope creep (új szerepkör, második platform, chat, fizetés vagy adminfunkció menet közbeni hozzáadása) és a 7-10 napos visszajelzési körök együtt gyakran több csúszást okoznak, mint a teljes kódolási idő. Ezt követik a külső integrációk, különösen a fizetés és a harmadik feles API-k, amelyek verifikációs átfutása nem a fejlesztőn múlik.

Mennyibe kerül és mennyi idő egy MVP fejlesztése?

Az idő és az ár szorosan összefügg, mert mindkettő a rögzített funkciólistából származik.

Fix scope, fix price modell ott működik jól, ahol a funkciólista a projekt elején írásban rögzül: ilyenkor az ügyfél előre tudja a költséget és a határidőt is. Nyitott scope esetén az óradíjas elszámolás a reálisabb, de akkor sem a határidő, sem a végösszeg nem garantálható előre.

A CompletApp például fix scope és fix ár mellett dolgozik, mérföldkő-alapú átadással, és a teljes kódtulajdonjog a végső fizetéskor az ügyfélhez kerül.

Lehetséges 4 hét alatt elkészíteni egy MVP-t?

Igen, de csak szigorú feltételek mellett.

Négy hét akkor reális, ha egyetlen core userflow-t építesz, a scope dokumentum a kickoff előtt jóváhagyott, és az ügyfél 24-48 órán belül dönt minden kérdésben.

Ha közben bejön egy második platform, egy payment-integráció vagy bővül az adminfelület, a négy hétből azonnal hét-nyolc lesz. Cross-platform keretrendszer, például Flutter használata segít, mert egy kódbázisból ad iOS és Android buildet.

Miért tart tovább az MVP fejlesztése, mint eredetileg tervezték?

Mert a legtöbb kezdeti becslés csak a kódolási időt tartalmazza, a naptári idő 30-50%-át pedig a körülötte lévő munka viszi el.

Scope-véglegesítés, designjóváhagyás, tartalom-előkészítés (szövegek, képek, jogi dokumentumok), tesztelési ciklusok és az áruházi review mind valós naptári napok.

Ehhez jön, hogy a kutatások szerint az MVP-k esetében eleve kevés a megbízható korai becslési gyakorlat, ezért 25-30% kockázati tartalék nélkül szinte minden terv optimista.

Milyen fázisai vannak az MVP fejlesztésnek?

Hat fázis van: discovery és scope-véglegesítés, UX/UI tervezés, fejlesztés, QA és bugfix, zárt béta, majd áruházi publikáció. A discovery 1-2 hét, a design 1-2 hét, a fejlesztés 2-12 hét komplexitástól függően, a QA fél-két hét, a béta 1-2 hét, a store review pedig néhány naptól két hétig terjed.

Ha egy ajánlat nem nevesíti mind a hat fázist, valószínűleg valamelyik hiányzik a becslésből.

Melyik Ütemterv Illik Hozzád?

Ha egyetlen core userflow-t kell validálnod befektetők vagy első felhasználók előtt, a 4 hetes fix scope modell a reális választás.

Egy demózható, működő termék többet ér egy 12 hetes, félkész platformnál.

Ha marketplace-t vagy több szerepkörös platformot építesz, tervezz 10-16 hetet, és tegyél külön mérföldkövet a fizetési flow-ra és az adminfelületre.

Ez a két elem szokta felborítani az ütemterveket.

A ma megtehető lépés viszont független attól, melyik kategóriába esel: írj egy scope dokumentumot a core felhasználói folyamatról, mielőtt fejlesztőt keresel. Sorold fel a képernyőket, a szerepköröket, az integrációkat, és jelöld meg, mi nem kerül bele.

Ez az egy dokumentum önmagában heteket spórolhat, és pontosabb ajánlatokat kapsz rá.

A becslés minősége ugyanis soha nem a fejlesztőn múlik elsősorban, hanem azon, mennyire tudod, mit akarsz építeni.