Spring til indhold

MVP

SaaS MVP-udvikling

Vi bygger SaaS-MVP'er der både kan vise produktet til de første kunder og bære videreudvikling i mange måneder efter. Ingen prototype-spaghetti, ingen tunge frameworks I aldrig kommer til at bruge.

InfrastrukturMulti-tenant DBAuth & billingAPI & jobsFrontend

På et øjeblik

Hvad du faktisk får

Typisk fra discovery til go-live
8–14uger
Auth, multi-tenancy og Stripe billing
Dag 1
Du ejer koden — i din GitHub
100%
Demoer fra fjorten dage inde i forløbet
Ugentlige

Sådan tænker vi MVP

Et MVP er ikke et halvfærdigt produkt.

En MVP er ikke et halvfærdigt produkt — det er det mindste produkt der løser et reelt problem for én tydelig kundetype. Vi har bygget en del af dem nu, og vi har lært at de bedste MVP'er er fokuserede, hurtige og bygget på en stack der ikke skal smides væk når der kommer 200 kunder. Det er ikke det samme som "hurtigt og beskidt" — det er hurtigt og fokuseret.

Vi arbejder i 8–14 uger fra idé-discovery til en kørende, betalt-for SaaS i produktion. Vi bygger på Next.js (App Router), Postgres (Supabase eller Neon), TypeScript, Tailwind og en håndfuld dokumenterede mønstre vi ved holder. Vi tager multi-tenancy, billing (Stripe), auth (med organisationer og roller) og email (Resend) med fra dag ét — fordi det er meget dyrere at proppe på senere end at bygge det rigtigt fra start.

Vi forstår at en startup-MVP og en intern proof-of-concept er forskellige bæster. En startup-MVP skal kunne udfordres af kunder der ikke kender jer, betaler med kreditkort, og er utålmodige. Vi bygger den med rigtig onboarding, en realistisk feature-roadmap og en plan for hvad der sker når jeres første store kunde spørger om SOC 2-bilag.

Processen

Fire faser. Ugentlige demoer. Ingen overraskelser.

Vi arbejder i korte iterationer med deploy fra dag ét, så I løbende kan se og bruge det vi bygger. Sluttiden er fast i discovery — scope er det vi justerer på undervejs hvis prioriteter ændrer sig.

  1. Uge 1–2

    Discovery & design

    Vi lægger MVP-scope, designer kerne-flows i Figma, vælger stack og laver en realistisk plan med ugentlige demoer. I går herfra med et tydeligt budget og en risikoliste — før vi rører en kodebase.

    • Scope-dokument og roadmap
    • Wireframes og design-system grundlag
    • Tech-arkitektur og stack-valg
    • Risikoliste og mitigationsplan
  2. Uge 3–6

    Foundation

    Vi bygger fundamentet: auth, multi-tenant data-isolation, billing og det interne værktøj jeres team selv vil bruge. Preview-deploys på hver pull request fra dag tre — så I løbende kan klikke rundt.

    • Auth.js eller Clerk med organisationer
    • Postgres med RLS og migrations
    • Stripe billing + Customer Portal
    • CI/CD pipeline + preview-environments
  3. Uge 7–10

    Features

    Nu kommer det jeres produkt faktisk handler om. 2–4 hovedfeatures bygget i tæt dialog med jer og — hvis muligt — de første pilot-kunder. Daglig deploy til staging, ugentlig demo.

    • 2–4 hovedfeatures fuldt fungerende
    • Onboarding-flow og brugerinvitation
    • Transaktionelle e-mails (Resend)
    • Mobile-responsive UI på hele produktet
  4. Uge 11–14

    Polish & launch

    Performance-tuning, sikkerhedsgennemgang, dokumentation og go-live. De første kunder onboardes med os ved hånden, og vi fortsætter med drift og videreudvikling efter aftale.

    • Performance & sikkerhedsgennemgang
    • Drifts-monitorering og on-call
    • Bruger- og admin-dokumentation
    • Soft launch med pilot-kunder

Hvad der kommer i æsken

Standard-stacken vi bygger på

Vi vælger anderledes hvor det giver mening — men sjældent. Den her stack lader os gå hurtigt uden at bygge teknisk gæld vi skal betale tilbage senere.

  • Next.js

    Frontend, SSR og API routes

  • TypeScript

    End-to-end type-sikkerhed

  • PostgreSQL

    Primær database (Supabase eller Neon)

  • Tailwind CSS

    Designsystem og UI

  • Vercel

    Edge-hosting og preview-deploys

  • Cloudflare

    DNS, WAF og edge-cache

  • Node.js

    Backend runtime og workers

  • Python

    ML- og data-pipelines hvor relevant

Hvad I får leveret

Det her er det vi rent faktisk bygger.

Færdigt på 8–14 uger. Ikke en tjekliste — det er sådan en typisk MVP-leverance ser ud i praksis.

  • Discovery og scope

    1–2 uger hvor vi lægger MVP-scope, designer kerne-flows, vælger stack og laver en realistisk plan med ugentlige demoer. I får et tydeligt budget og en risikoliste, ikke en estimat-magisk tale.

  • Multi-tenant arkitektur

    Organisationer, brugere, invitationer, roller og data-isolation fra dag ét. Bygget på proven Postgres-mønstre (Row-Level Security eller schema-isolation) så det skalerer fra 1 til 1000 tenants uden re-design.

  • Auth og brugerstyring

    E-mail/adgangskode, magic links, Google og Microsoft SSO. Inviter-flow, password reset, MFA hvor det giver mening. Bygget på Auth.js, Clerk eller WorkOS afhængigt af hvor I skal hen.

  • Billing med Stripe

    Subscription, trial, pr.-bruger eller pr.-forbrug, fakturaer og selvbetjening via Stripe Customer Portal. Webhook-håndtering med idempotens — så I aldrig opkræver to gange eller mister en betaling.

  • Transaktionelle e-mails

    Velkomst, invitationer, fakturaer, alarmer og notifikationer leveret pålideligt via Resend eller Postmark. Med templates der ligner produktet og open/click-tracking hvor I vil have det.

  • Drift, monitoring og support

    Vercel eller AWS hosting, Postgres med backups, Sentry til fejlrapportering og en lille on-call rotation hvor vi tager pinget når noget brænder uden for arbejdstid.

Scope

Tre engagement-niveauer. Vælg det der matcher ambitionen.

Vi taler altid scope og pris i discovery — aldrig på en hjemmeside. Det her er rammerne vi typisk arbejder indenfor, så I kan se hvor jeres MVP nogenlunde lander før vi mødes.

  • Lean

    8–10 uger

    Fokuseret MVP til at validere idéen med de første betalende kunder. Får jer hurtigt i markedet.

    • Auth + multi-tenant fra dag 1
    • Stripe billing med trial
    • 1–2 hovedfeatures
    • Vercel hosting + Sentry
    • GitHub setup + CI/CD
    • 4 ugers stabilisering
  • Vores anbefaling

    Standard

    10–12 uger

    Komplet MVP for de fleste startup-cases. Vores anbefaling til langt de fleste.

    • Alt i Lean
    • 3–4 hovedfeatures
    • Avanceret rolle-styring
    • Transaktionelle e-mails
    • Onboarding-flow med invitationer
    • Admin-dashboard
  • Komplet

    12–14 uger

    Større scope med integrationer, compliance og avanceret arkitektur. For B2B og regulerede brancher.

    • Alt i Standard
    • 5–7 hovedfeatures
    • 3+ eksterne integrationer
    • GDPR + SOC 2-klar arkitektur
    • Custom analytics & rapportering
    • Pilot-onboarding-support

Hvert niveau dækker discovery, build, drift-opsætning og 4–6 ugers stabilisering efter go-live. Drift og videreudvikling aftales separat efter go-live.

Inden vi går i gang

Det her bør I overveje først.

  • Valg af stack

    Vi defaulter til Next.js + Postgres + TypeScript fordi den stack er hurtig at bygge i, hurtig at hyre på og hurtig at drifte. Hvis I har en god grund til en anden stack (eksisterende team, integration med en .NET-backend, særlige performance-krav), så bruger vi det. Men vi vælger først stack når vi har talt om hvad der skal bygges — ikke omvendt.

  • Tidshorisont og scope

    8–14 uger er normalområdet for en MVP der inkluderer auth, multi-tenancy, billing og 2–4 hovedfeatures. Hvis scope er mindre (intern PoC), kan vi gøre det på 4–6 uger. Hvis scope er større (du har en feature-liste på 30 punkter), så skal vi tale om hvad der kommer i version 1 og hvad der venter — for et 30-punkts MVP er ikke en MVP.

  • Pricing og forretningsmodel

    Vi er ikke jeres CFO, men vi har set mange pricing-modeller. Vi sætter Stripe op så I kan eksperimentere — månedlig vs. årlig, pr. bruger vs. pr. forbrug, free trial vs. pilot — uden at det kræver kode-ændringer hver gang. Det er vigtigere at kunne ændre prismodellen efter en måned end at ramme den perfekt fra start.

  • Hvem ejer koden

    I ejer koden. Den ligger i jeres GitHub-organisation fra dag ét, jeres team får adgang og I kan tage den et andet sted hen hvis vi ikke længere er den rette partner. Vi tror på at gode aftaler ikke er bygget på lock-in.

FAQ

Det folk plejer at spørge om.

  • Hvad sker der i discovery-fasen?

    I to korte uger fastlægger vi MVP-scope, designer kerne-flows i Figma, vælger stack og bygger en realistisk plan med ugentlige demoer. I går herfra med et tydeligt scope, en risikoliste og et åbent budget — før vi rører en kodebase. Pris og scope diskuterer vi altid privat i dialogen, ikke på en hjemmeside.

  • Hvor hurtigt kan vi være live?

    8–14 uger fra første samtale til betalende kunder er normalt for en fokuseret MVP. Vi kører ugentlige demoer fra uge 2, har preview-deploys på hver pull request, og lader jer (eller jeres første pilot-kunder) prøve produktet løbende. "Live" er ikke en magisk dato — det er en gradvis udrulning hvor vi går fra interne testere til pilot-kunder til offentlig launch.

  • Hvem ejer koden?

    I gør. Repository ligger i jeres GitHub-organisation fra dag ét, jeres team kan få commit-adgang når I ønsker det, og hele kodebasen er jeres ejendom. Vi tror ikke på lock-in. Hvis I på et tidspunkt vil tage videreudviklingen ind selv eller bruge et andet bureau, så er det jeres beslutning — vi laver en ordentlig handover og forsvinder pænt.

  • Hvad sker der efter MVP'en er live?

    Det afhænger af hvad I vil. Mange kunder vælger en månedlig drifts- og videreudviklingsaftale hvor vi tager nye features, support, sikkerhedsopdateringer og drift på fast pris. Andre tager videreudviklingen selv og lader os stå for kun drift. Eller en mellemvariant hvor vi er backup når jeres team er presset. Vi taler om det i god tid før go-live — det skal ikke komme som en overraskelse.

  • Hvordan ved I at MVP'en bliver bygget rigtigt?

    Vi arbejder efter en stack og et sæt mønstre vi har brugt på flere SaaS-bygninger og som vi ved holder. Vi laver weekly demoer så I kan se fremdriften, vi har preview-deploys på hver pull request så I løbende kan teste, og vi laver kode-review internt så ingen kode går i produktion uden at have været set af to par øjne. Og når noget alligevel går galt — for det gør det — så fikser vi det og lærer af det. Det er forskellen på et team der har bygget den her slags før og et team der bygger det for første gang.

Klar til at starte?

Lad os tage en uforpligtende snak.

Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.