SaaS & MVP
Næsten hvert SaaS-projekt vi starter i discovery har samme spænding: produktejeren vil have "det hele" i v1, og engineering ved at hver ekstra modul forlænger tiden til første rigtige bruger-feedback.
Her er hvordan vi typisk skærer scope — ikke som en rigid checkliste, men som de beslutninger der holder et MVP fokuseret nok til at lære noget.
TL;DR
De vigtigste pointer
- v1 skal løse ét kerneproblem for én primær bruger-type — resten er distraktion.
- Auth, grundlæggende data-model og ét betalings- eller onboarding-flow hører typisk med.
- Admin-paneler, avanceret RBAC, webhooks og white-label venter ofte til efter første betalende kunder.
- Multi-tenant isolation skal tænkes ind fra start — selv hvis I kun har én tenant i v1.
Hvorfor scope glider — og hvordan I stopper det
Scope glider fordi "bare en lille admin-side" sjældent er lille, og fordi stakeholders sammenligner med modne produkter brugerne allerede kender. Et MVP skal være skamfuldt simpelt målt på features — og skarpt på det ene flow der beviser værdien.
Vi skriver scope som user stories med acceptkriterier og en eksplicit "ikke i v1"-liste. Den liste er lige så vigtig som backlog'en. Uden den ender I med et halvfærdigt produkt der prøver at være alt.
Fem spørgsmål der afklarer v1-scope
Gennemgå dem i discovery — svarene bliver jeres scope-kontrakt.
- 01
Hvem er den første bruger — og hvad skal de kunne afslutte?
Ét primært job-to-be-done. Hvis I har tre lige vigtige brugertyper, har I endnu ikke et MVP — I har tre halve produkter.
- 02
Hvordan ved I at nogen får værdi?
Definér ét målbart signal: signup der gennemfører onboarding, første export, første betaling. Byg kun det der fører dertil.
- 03
Hvad er minimum for auth og data?
Typisk: login, grundlæggende profil, tenant-scoping i databasen. Ikke: SSO, custom roles, audit log — medmindre compliance kræver det fra dag ét.
- 04
Skal der betales i v1?
Hvis ja: én plan, Stripe Checkout, webhook der aktiverer adgang. Ikke: fakturaer, metered billing, coupons og selvbetjent downgrade i første release.
- 05
Hvad siger I bevidst nej til?
Skriv det ned. "Ingen API i v1", "ingen mobil-app", "ingen import fra Excel". Det er jeres forsvar mod scope der kommer tilbage som "det tager jo bare en dag".
Spørgsmål vi får igen og igen
Skal vi have et admin-panel i v1?
Kun hvis interne brugere ikke kan klare sig med database-værktøjer eller en midlertidig intern side. Et fuldt admin-UI sluger ofte uger. Spørg: kan vi supporte de første ti kunder uden det?
Hvad med API og webhooks?
Tilføj når en betalende kunde eller integration kræver det — ikke fordi "alle SaaS har et API". v1 kan være kun UI, hvis det er det flow I validerer.
Kan vi skippe betalinger i v1?
Ja, hvis I manuelt onboarder pilotkunder og lærer på feedback før I tager betaling. Men hvis hypotesen er "folk betaler for det her", skal betaling med i v1 — ellers beviser I kun engagement, ikke willingness to pay.
Hvor mange features er for mange?
Hvis I ikke kan demo'e kerne-flowet på under fem minutter, er scope for stort. Skær til I kan — eller del op i faser med navngivne releases, så I stadig shipper noget tidligt.
Står I midt i scope-diskussionen?
Lad os skære v1 så det kan shippes — og stadig lærer noget.
Vi hjælper med at prioritere hvad der hører hjemme i første release, og hvad der bevidst venter. Ærligt — også hvis det betyder færre features end I havde håbet.