Koliko traje razvoj web aplikacije (i što sve utječe na rok)

“Koliko će ovo trajati?” pitanje je koje slijedi odmah nakon “koliko košta”. I jedno je od onih u kojima se najlakše izgubi pošten odgovor — agencije skraćuju brojeve da dobiju posao, klijenti čuju kraći broj jer im to bolje paše, i obje strane se iznenade tri mjeseca kasnije kad postane jasno da početni rok nije bio realan.

Ovaj tekst razlaže kako rokovi stvarno izgledaju u 2026., što ih najčešće produžuje i — što je možda najvažnije — što vi kao klijent možete učiniti da projekt teče po planu.

Realni rasponi trajanja u 2026.

Za tipične projekte s timom od 3 do 5 ljudi:

Ako vam netko obeća kompleksnu aplikaciju “za 6 tjedana”, on ili ne razumije opseg ili priprema teren za naknadnu raspravu o produljenju. Ako vam za jednostavan MVP traži 6 mjeseci, to je signal preinženjeringa ili podijeljene pažnje tima.

Faze razvoja i koliko stvarno traju

Razvoj nije jedan kontinuirani blok — sastoji se od faza koje se preklapaju, ali svaka ima svoje minimalno trajanje. Ako se pokuša ubrzati ispod tih minimuma, kvaliteta pada.

Discovery i specifikacija — 1 do 3 tjedna

Tu se definira problem, korisnici, ključni tijekovi, tehnička arhitektura i ono što izričito ne gradite. Ova faza često je nepopularna (“ali još ne kodiramo”) i zato je prva koja se reže — što je obično razlog zašto projekti kasnije kasne.

Trajanje ovisi o jasnoći ideje. Ako znate točno što gradite i tko je korisnik, jedan tjedan je dovoljan. Ako još uvijek razgovarate o tome je li to B2B ili B2C, treba vam tri tjedna i pravi savjetnik.

Dizajn — 2 do 6 tjedana

UI/UX dizajn za standardnu web aplikaciju traje 3 – 4 tjedna. Za jednostavni MVP — 2 tjedna. Za kompleksnu platformu s puno različitih korisničkih uloga — 4 do 6 tjedana.

Dizajn se može preklapati s razvojem nakon prvog tjedna. To je zdrava praksa — dizajner radi sekundarne ekrane dok developeri grade osnovu.

Razvoj — 6 do 24 tjedna

Najveći blok. Tipična podjela:

• Sprint 0 (priprema, infrastruktura, baza): 1 – 2 tjedna
• Sprint 1 — kostur: ključni korisnički tijek od početka do kraja, autentikacija, baza
• Sprint 2 — sekundarne funkcionalnosti: integracije, dodatne stranice, dotjerivanje
• Sprint 3+ — proširenja, kompleksne funkcije, ovisno o veličini projekta

Standardni sprint traje 2 tjedna. Aplikacija srednje složenosti tipično prolazi kroz 4 do 7 sprintova razvoja.

QA i testiranje — 1 do 3 tjedna

Posebna faza posvećena testiranju. Često se reže. Ako se reže, problemi koji su trebali biti uhvaćeni ovdje pojavljuju se prvi tjedan u produkciji — i koštaju 5 do 10 puta više za popravak.

Priprema lansiranja i deployment — 1 do 2 tjedna

Konfiguracija produkcije, monitoring, backup, dokumentacija, edukacija vašeg tima. Bez novih funkcionalnosti.

Realan primjer: 16 tjedana za standardnu B2B aplikaciju

Da brojevi imaju kontekst, evo kako tipično izgleda 16-tjedni razvoj B2B platforme s budžetom od 30.000 €:

Brojevi nisu fiksni. Razvoj se može preklapati s dizajnom, QA može trajati duže ako se pojave kritični bugovi. Ali raspored postotaka u praksi je dosta stabilan.

Što stvarno produžuje rokove

1. Nedovoljno definiran početak. Najčešći razlog kašnjenja nije sporost tima — to je opseg koji nije bio jasan kad je razvoj krenuo. Svako pitanje koje se mora odlučivati tijekom razvoja troši barem dvostruko više vremena nego što bi trošilo da se odlučilo unaprijed.

2. Sporo donošenje odluka na vašoj strani. Ovo je zaista najveća skrivena varijabla. Ako vam developeri pošalju demo u ponedjeljak, a vi povratnu informaciju date sljedeću srijedu, projekt je upravo izgubio osam radnih dana. Pomnožite to s 5 – 10 ciklusa odlučivanja u tipičnom projektu, i tu su 2 mjeseca kašnjenja koja nemaju veze s timom.

3. Promjene opsega tijekom razvoja. Svaki “samo još jedna mala stvar” koji se prihvati tijekom razvoja produžuje projekt. Pojedinačno, dodatak može biti pola dana posla — ali najčešće dolazi s redizajnom, koordinacijom i testiranjem koje se kompresira na 2 – 3 dana.

4. Integracije s vanjskim sustavima. Najnepredvidiviji izvor kašnjenja. Integracija sa Stripeom traje dan-dva. Integracija sa zatvorenim enterprise CRM-om može pojesti cijeli sprint zbog dokumentacije koja ne odgovara stvarnosti, sandbox okruženja koje ne radi i timova s druge strane koji odgovaraju za 5 dana.

5. Vlasnik proizvoda nije dostupan. Projektu treba osoba na vašoj strani koja može donositi odluke u realnom vremenu. Ako tu osobu morate svaki put zvati i ona vam odgovara nakon dana ili dva, projekt usporava na pola brzine.

6. Tim koji radi paralelno na više projekata. Tim posvećen samo vašem projektu radi 2 – 3 puta brže od tima koji vas dijeli s 4 – 5 drugih projekata. Tu razliku se može vidjeti u svakom statusu napretka.

7. Tehnički izazovi koji se otkriju tek u praksi. Performanse koje su izgledale dobro u dizajnu ne rade na stvarnim podacima. Integracija koja je trebala biti jednostavna otkrije rubne slučajeve. Ovo je normalno — i baš zato dobri planovi imaju 15 – 20 % rezerve, a ne plan koji je već “presjeck”.

Što vi kao klijent možete učiniti da projekt ide brže

Polovica utjecaja na trajanje projekta je u rukama tima. Druga polovica je u vašima. Konkretne stvari koje stvarno ubrzavaju:

Imenujte jednog vlasnika proizvoda. Jedna osoba na vašoj strani s ovlasti za odluke o opsegu, dizajnu i prioritetima. Ne komitet. Ne “moramo to provjeriti s upravom”. Komiteti udvostručuju trajanje svake odluke.

Odgovarajte u 24 sata. Postavite to kao obavezu. Ako developer šalje pitanje koje blokira napredak, treba vaš odgovor isti ili sljedeći dan. To što se odlučivanje često događa preko vikenda ili tijekom godišnjeg odmora razlog je zašto projekti gube tjedne.

Dolazite na demoe pripremljeni. Demo nije promatranje. Trebate aktivno gledati, klikati, postavljati pitanja, davati feedback. Demo bez angažmana s vaše strane je sastanak koji ništa ne miče.

Sva pitanja imajte u jednom mjestu. Slack kanal, Notion stranica, Trello board — sve jedno. Pitanja razasuta po e-mailu, WhatsAppu i SMS-u jamačno znače da nešto propada.

Donesite odluku jednom i držite je. Najveći ubojica brzine je promjena već donesenih odluka. “Sad kad smo to vidjeli, mislim da bismo ipak trebali…” je razlog zašto projekti od 12 tjedana traju 18.

Dvije razine “kašnjenja” — koju imate

Ne kasne svi projekti na isti način. Postoje dvije vrste:

Realno kašnjenje: tim je dao rok od 14 tjedana, sad se čini da će biti 17. Razlog je izmjena opsega ili integracija koja se pokazala kompleksnijom. Ovo je normalno i prihvatljivo, ako se rano komunicira.

Strukturalno kašnjenje: tim je dao rok od 14 tjedana, prošlo je 12, a očito nije ni blizu kraja. Tjedni izvještaji su nejasni, demoi se otkazuju, “još malo” postaje stalan odgovor. Ovo je ozbiljan problem. Obično znači da tim nije imao pravi plan ili je opseg dramatičnije šire nego što su procijenili. U takvoj situaciji potreban je hitan razgovor o reset-u plana, ne nastavak po inerciji.

Razlika između prve i druge: transparentnost. Tim koji rano kaže “kasnimo, evo zašto i evo prijedloga” je tim s kojim ćete uspjeti. Tim koji vas drži u neizvjesnosti je crveni signal koji ne ignorirajte.

Što očekivati u različitim fazama (signali da sve ide kako treba)

Tjedan 2 – 3 (kraj discoveryja): imate dokument o opsegu, tehničku specifikaciju, popis “što ne radimo”. Ako u ovoj fazi nije sve crno na bijelom, projekt će kasno.

Tjedan 5 – 6 (kraj dizajnerske faze): vidite klikabilan prototip ključnih ekrana. Ako još uvijek gledate samo statične mockupove, dizajn nije gotov.

Tjedan 8 – 10 (sredina razvoja): imate radnu staging verziju aplikacije gdje možete proći ključni korisnički tijek. Funkcionalnosti nisu dotjerane, ali rade. Ako nakon 8 tjedana nemate ništa što biste mogli pokazati, postoji razlog za zabrinutost.

Tjedan 13 – 14 (pred kraj razvoja): aplikacija je funkcionalno gotova, kreće QA. Lista bugova bi trebala se kratiti, ne rasti.

Tjedan 15 – 16 (lansiranje): deployment, edukacija vašeg tima, dokumentacija. Bez novih funkcionalnosti — fokus je samo na stabilnosti.

Suština

Realni rokovi razvoja web aplikacije u 2026. kreću se od 4 do 8 tjedana za MVP do 6 do 12 mjeseci za kompleksne enterprise sustave. Većina ozbiljnih projekata završava u 3 do 5 mjeseci.

Trajanje ovisi o opsegu, kompleksnosti, jasnoći specifikacije i — možda najvažnije — koliko brzo donosite odluke kao klijent. Brzina vašeg odgovora i fokus jednog vlasnika proizvoda imaju veći utjecaj na rok od izbora tehnologije ili veličine tima.

Najveće kašnjenja ne dolaze iz krivih procjena. Dolaze iz ulazaka u razvoj prije nego što su važne odluke bile donesene. Tjedan ili dva uloženi u jasnu specifikaciju štede mjesec ili dva izgubljen na “to ipak nije ono što smo htjeli”.

Razmišljate o razvoju i trebate realnu procjenu trajanja? Nakon kratkog discovery razgovora možemo procijeniti opseg i dati vam realan raspon trajanja za vaš tip projekta — sa svim faktorima koji mogu utjecati na rok. Javite nam se. Više o našem pristupu pogledajte na stranici Razvoj web aplikacija.