Agencijski playbook: Kako lansirati SaaS u 90 dana (opseg, tim, stack i kontrola rizika)

# Uvod: 90-dnevno lansiranje SaaS-a je problem opsega i rizika#

Da biste lansirali SaaS u 90 dana, ne trebaju vam superherojski developeri. Treba vam plan koji drži opseg uskim, rano otkriva rizike i tjera donošenje odluka prije nego što postanu skupe.

Čest obrazac koji viđamo: timovi potroše 4 do 6 tjedana na “rad na temeljima”, kasno otkriju ograničenja integracija, a zatim pokušaju stisnuti testiranje i onboarding u zadnja dva tjedna. Tu se lansiranja odgađaju i kvaliteta pada.

Ovaj playbook je realističan 90-dnevni plan s milestoneovima, ulogama, granicama opsega i kontrolnim točkama odlučivanja. Optimiziran je za Samioda delivery stack: Next.js i React za web, Flutter za mobilno te n8n za automatizaciju.

Ako želite širi agencijski workflow iza ovoga, krenite s pregledom našeg procesa: Proces razvoja weba korak po korak. Ako uspoređujete in-house i agencijsku isporuku, pogledajte Vodič za outsourcing web razvoja.

# Što “lansiranje” znači u ovom playbooku#

Lansiranje u 90 dana nije “feature complete”. To je MVP spreman za izdavanje koji može dovesti korisnike, naplaćivati ako je potrebno i podržati ponovljiv onboarding flow.

Definicija “gotovo” za 90-dnevno SaaS lansiranje#

Vaš MVP treba pouzdano isporučiti:

• Jedan ključni workflow koji rješava jedan bolan posao za jednu ciljnu personu
• Autentifikaciju i osnovno upravljanje računom
• Naplatu i ograničavanje po planovima ako prihod kreće odmah
• Kanal podrške i nadzor grešaka
• Mjerljiv onboarding funnel od posjeta do aktivacije

ℹ️ Napomena: Ako ne možete definirati aktivacijski događaj u jednoj rečenici, ne možete planirati isporuku u 90 dana. Primjer: “Korisnik uveze podatke i generira svoje prvo izvješće unutar 10 minuta.”

Granice opsega koje štite 90-dnevni raspored#

Ovo su najčešći ubojice rokova. Po defaultu ih postavite na “ne”, osim ako su upravo to proizvod.

Ako stakeholderi traže više “must-have” stavki, prisilite tradeoffove pristupom fiksnog kapaciteta. 90-dnevni plan pretpostavlja stabilnu baznu definiciju opsega nakon 2. tjedna.

# Tim i uloge: minimalna postava koja stvarno isporučuje#

Možete graditi i s manje uloga, ali ćete platiti kroz rework i propuštene rizike. Cilj je zadržati malo handoffova i jasnu odgovornost.

Preporučeni tim za 90-dnevni MVP#

Pravilo donošenja odluka koje vas drži u rasporedu#

Svaka neriješena odluka postaje skriveno kašnjenje. Koristite jednog odgovornog vlasnika po domeni:

• Produkt odluke: Product Owner
• Tehničke odluke: Tech Lead
• Go-to-market odluke: Founder ili Growth Lead

⚠️ Upozorenje: Izbjegavajte komitete za odobravanje UX-a i opsega. Kada pet ljudi odobrava ekran, nitko ne posjeduje ishod, a rokovi klize bez jasnog “zašto”.

# Odabir stacka koji optimizira brzinu i kontrolu rizika#

Lansiranje u 90 dana je uglavnom smanjivanje nepoznanica i minimiziranje površine. Samiodin stack je za to vrlo prikladan kada se koristi namjerno.

Web-first SaaS: Next.js i React#

Koristite Next.js kada:

• Trebate brzu iteraciju i snažan ekosustav za auth, naplatu i UI
• Želite SEO ili indexabilne landing stranice
• Želite ujedinjen full-stack pristup s API routes ili server actions, ovisno o arhitekturi

Konkretne prednosti:

• Brže time-to-first-feature zbog zrelih patterna
• Jednostavan deployment na uobičajenim platformama
• Jednostavno spajanje marketing stranica i aplikacije u jedan repo

Mobilno: Flutter kada je mobilno ključan put korištenja#

Koristite Flutter pri lansiranju kada je barem jedno točno:

• Primarno korištenje proizvoda odvija se na mobitelu
• Trebate offline mode ili device mogućnosti rano
• Trebate jednu codebase za iOS i Android kako biste ostali u budžetu

Ako je mobilno “nice to have”, prvo isporučite responsive web app, a zatim dodajte Flutter u sljedećem ciklusu od 60 do 90 dana.

Automatizacija: n8n za ops i integracijsko “ljepilo”#

n8n smanjuje ručni rad koji bi inače zahtijevao custom code:

• Usmjeravanje leadova iz formi u CRM
• Emailovi životnog ciklusa korisnika temeljeni na eventovima
• Triage podrške i workflowovi eskalacije
• Sinkronizacija podataka između Stripea, vaše baze i spreadsheetova za rano izvještavanje

💡 Savjet: n8n workflowove tretirajte kao assets prve klase. Verzije, dokumentacija i ownership su bitni, jer puknute automatizacije mogu tiho ubiti onboarding i retention.

# Plan od 90 dana: faze, milestoneovi, isporuke i kontrolne točke#

Ovaj plan je dizajniran oko tjednih isporuka i eksplicitnih go/no-go “gateova”. Pretpostavlja sprintove od dva tjedna, ali isporučuje nešto upotrebljivo svaki tjedan.

Faza 0: Pre-flight (Dani 1 do 3) — Uskladite ishode, ne featuree#

Cilj: Zaključati personu, core job i aktivacijski događaj.

Isporuke:

Checkpoint A: gate održivosti MVP-a (Dan 3)
Nastavite samo ako su aktivacijski događaj i v1 opseg jasni i testabilni.

Faza 1: Discovery i smanjenje rizika (Dani 4 do 14) — Ubijte nepoznanice rano#

Cilj: Razriješiti najrizičnije pretpostavke dok dizajn i inženjering idu paralelno.

Ključni rizici koje treba prvo adresirati:

• Izvedivost integracija: payment provider, auth, uvoz podataka, third-party API-ji
• Jasnoća data modela: koje entitete imate i kako su povezani
• Ograničenja onboardinga: što korisnik mora napraviti prije nego što se pojavi vrijednost

Isporuke:

Praktičan template za risk register#

Vodite jednostavan risk log. Pregledajte ga tjedno.

Checkpoint B: zamrzavanje arhitekture i opsega (Dan 14)
Zamrznite MVP opseg. Promjene nakon ovoga moraju se kompenzirati tradeoffom s nečim drugim.

# Faza 2: Izgradite vertical slice (Dani 15 do 28) — Jedan flow end to end#

Cilj: Isporučiti funkcionalan “tanak” slice proizvoda koji dokazuje cijeli lanac: UI, API, podatke, auth i deployment nalik produkciji.

Vertical slice treba podržati:

• Sign up i sign in
• Kreiranje ili uvoz core entiteta
• Dovršavanje core akcije
• Pregled outputa koji predstavlja vrijednost

Primjeri isporuka:

Primjer: n8n workflow za onboarding i support triage#

Držite ga malim i mjerljivim. Krenite s “new signup” i “failed payment”.

# Minimal workflow checklist (implementation varies by n8n setup)
1) Trigger: Webhook "user.created"
2) Action: Send transactional email "Welcome + 3-step checklist"
3) Wait: 24h
4) IF: user not activated
5) Action: Create support ticket + notify Slack channel

🎯 Ključna poruka: Do 28. dana ne ciljate na poliranje. Dokazujete da core workflow radi u produkcijskim uvjetima.

Checkpoint C: prihvaćanje vertical slicea (Dan 28)
Ako vertical slice nije stabilan, nemojte dodavati featuree. Popravite pouzdanost i onboarding prije širenja opsega.

# Faza 3: Dovršavanje MVP featurea (Dani 29 do 56) — Gradite samo ono što podržava aktivaciju#

Cilj: Dovršiti MVP featuree koji direktno poboljšavaju aktivaciju, retention i monetizaciju.

Ovdje timovi najčešće “odlete”. Držite strogi redoslijed prioriteta:

1. 1
   Blokatori aktivacije
2. 2
   Driveri retentiona
3. 3
   Monetizacija i ograničavanje po planovima
4. 4
   Admin i support alati

Tipičan MVP feature set za B2B SaaS#

Primjer koda: osnovni server-side feature gating u Next.js#

Plan gating držite jednostavnim. Izbjegavajte kompleksne entitlemente u v1.

export function canAccessFeature(user, featureKey) {
  const plan = user?.plan || "free";
  const matrix = {
    free: ["core"],
    pro: ["core", "exports"],
  };
  return (matrix[plan] || []).includes(featureKey);
}

Gdje React i Next.js smanjuju delivery rizik#

• Reuse komponenti smanjuje UI drift između marketinga i aplikacije
• Zrele biblioteke za forme i validaciju smanjuju edge caseove
• Opcije SSR-a i cacheiranja pomažu performansama bez prepisivanja aplikacije

Checkpoint D: spremnost za betu (Dan 56)
Prijeđite na betu samo ako je onboarding funnel mjerljiv end-to-end i core workflow uspijeva za interne testne račune.

⚠️ Upozorenje: Ne pokrećite betu bez instrumentacije. Ako ne možete mjeriti drop-offove, ne možete popraviti aktivaciju, a beta feedback postaje šum mišljenja.

# Faza 4: Beta lansiranje i hardening (Dani 57 do 77) — Smanjite churn prije skaliranja#

Cilj: Dovesti stvarne korisnike u proizvod, popraviti glavne failure modove i učvrstiti pouzdanost.

Dobar beta target je 10 do 30 korisnika koji odgovaraju vašoj personi. Za mnoge B2B proizvode to je dovoljno da otkrije najveće UX i data probleme.

Beta hardening checklist#

Korištenje n8n za smanjenje support opterećenja tijekom bete#

Primjeri koji odmah štede vrijeme:

• Auto-kreiranje support ticketa kada se pojavi kritična greška
• Obavijest Slack kanalu kada korisnik dvaput ne uspije onboarding
• Slanje emaila “nudimo pomoć” kada se ne detektira aktivacijski događaj nakon 48 sati

To je često brže nego graditi in-app support featuree u v1.

# Faza 5: Spremnost za lansiranje i javno izdanje (Dani 78 do 90) — Isporuka i mjerenje#

Cilj: Javna objava uz predvidljiv ops, jasne poruke i sigurnost rollbacka.

Ova faza je o stabilnosti i go-to-market izvedbi, ne o novim featureima.

Launch isporuke#

Kontrolna točka odluke: Go ili no-go (Dani 85 do 88)#

Koristite objektivne kriterije za lansiranje:

• Stopa aktivacije u beti zadovoljava vaš minimalni prag
• Nema neriješenih kritičnih bugova u core workflowu
• Support response loop funkcionira
• Billing radi za barem pet stvarnih transakcija ako monetizirate

Ako trebate kontekst troškova za planiranje lansiranja, uskladite budžet rano koristeći benchmarke poput Cijena web stranice 2026. Iako je SaaS drugačiji od marketing stranice, iste budžetske greške vrijede: nejasan opseg i kasne promjene.

# Upravljanje rizikom: kontrolni sustav koji sprječava raspad 90-dnevnih planova#

90-dnevni plan propada kada se rizici otkrivaju kasno. Vaš posao je pomaknuti otkrivanje rizika u prvih 30 dana.

Četiri najveća rizika i kako ih kontrolirati#

Kontrolne točke odlučivanja koje nameću disciplinu#

Koristite eksplicitne checkpointove kao gateove. Ako prođete, nastavite graditi. Ako ne, stabilizirate.

1. 1
   Dan 3: gate održivosti MVP-a
2. 2
   Dan 14: gate zamrzavanja opsega i arhitekture
3. 3
   Dan 28: gate prihvaćanja vertical slicea
4. 4
   Dan 56: gate spremnosti za betu
5. 5
   Dani 85 do 88: launch go/no-go gate

Ovi checkpointovi smanjuju sunk-cost bias. Prisile vas da riješite teške probleme dok je promjena još jeftina.

# Primjer nacrta opsega: realističan MVP koji možete lansirati u 90 dana#

Ovo je primjer strukture MVP opsega koji se uklapa u rok za mnoge B2B SaaS proizvode.

Uključeno u v1#

Eksplicitno isključeno iz v1#

Ako se stakeholderi ne slažu s isključenjima, prisilite zamjenu. Raspored ostaje fiksan, pa opseg mora biti elastičan.

# Kako Samioda ovo tipično izvodi (bez over-engineeringa)#

Strukturiramo isporuku da proizvodi tjedni dokaz, ne tjedna obećanja.

• Next.js i React za web aplikaciju i marketing stranice u jednoj kohezivnoj codebase
• Flutter samo kada je mobilno nužno za core usage, ne kao default
• n8n za ranu automatizaciju onboardinga, billing opsa i support workflowova
• Release train koji isporučuje svaki tjedan, s kratkim QA prozorom i jasnim rollback planovima

Ovaj pristup se uklapa u transparentan model isporuke sličan našem dokumentiranom procesu: Proces razvoja weba korak po korak. Također odgovara timovima koji žele brzinu bez izgradnje velikog internog odjela, zbog čega outsourcing može biti učinkovit kada se pravilno upravlja: Vodič za outsourcing web razvoja.

# Ključne poruke#

• Definirajte “lansiranje” kao mjerljiv ishod MVP-a, a ne listu featurea, i zaključajte aktivacijski događaj do 3. dana.
• Zamrznite MVP opseg do 14. dana i prisilite tradeoffove za svaku promjenu kako biste zaštitili rok od 90 dana.
• Izgradite vertical slice do 28. dana koji dokazuje cijeli lanac: UX, auth, podatke, integracije, deployment i monitoring.
• Koristite n8n rano za automatizaciju onboardinga i support workflowova kako ne biste trošili inženjersko vrijeme na ops-teške featuree.
• Provodite eksplicitne go/no-go checkpointove 28., 56. i 85. dan(a) kako biste spriječili kasno otkrivanje rizika i kolaps kvalitete.
• Preferirajte Next.js i React za brzinu web-first MVP-a, a Flutter dodajte samo kada je mobilno primarni kanal korištenja od prvog dana.

# Zaključak#

Da biste lansirali SaaS u 90 dana, trebaju vam nemilosrdne granice opsega, tjedni dokazi u uvjetima sličnim produkciji i sustav kontrole rizika koji nameće rane odluke. Većina timova ne propada zato što ne može graditi brzo; propada zato što predugo gradi pogrešne stvari.

Ako želite da Samioda pomogne u definiranju MVP opsega za 90 dana, postavljanju Next.js ili Flutter temelja te automatizaciji operacija uz n8n, javite nam se kroz naše usluge web razvoja i mapirat ćemo vaših prvih 90 dana u plan koji se može isporučiti.