Metode
Korte loops, klare leverancer, ingen mellemmænd.
Du taler direkte med dem der skriver koden. Vi arbejder i overskuelige iterationer, deployer fra dag ét, og overdrager noget der kan drives bagefter — ikke en pose teknisk gæld.
Det her ligger fast
Det vi leverer på, hver gang.
- Demo og rytme — fra build-fase 1
- Ugentligt
- Preview-deploy så I tester før merge
- Pr. PR
- Samme team fra discovery til drift
- Ende-til-ende
- I ejer kode, infra og dokumentation
- Open by default
Hvorfor sådan
Vi har skåret det til der virker.
Vi har prøvet det modsatte: lange discovery-faser med tunge kravspecs, store teams hvor information går tabt mellem rollerne, og overdragelser hvor ingen ved hvor knapperne er. Det her er reaktionen på det — en arbejdsform der prioriterer korte loops, direkte adgang og en overdragelse hvor lyset er tændt.
Vores metode er ikke en metodologi med stort M. Det er en samling rytmer og leverancer vi vender tilbage til, fordi de gør færre antagelser og giver dig flere reelle valg undervejs. Du ser fremgang hver uge, du kan stoppe når du vil, og det vi bygger overlever den dag vi forlader projektet.
De tre faser
Discovery → Build → Drift.
Hver fase har en klar start, en klar slutning og konkrete leverancer. Vi går ikke videre uden at I har sagt go.
- 01Fase 01 · Discovery
Vi forstår problemet før vi løser det.
1–2 uger sammen om at forstå produktet, brugerne, constraints og hvad et realistisk første snit ser ud. Vi kører workshops, taler med jeres team, og stiller de spørgsmål der senere viser sig at være de vigtige. I slutningen ved I om vi er det rette match — og hvad et konkret build-engagement koster i tid og opmærksomhed.
- Skitse til arkitektur og tech-valg
- Realistisk tidsplan og milestones
- Risici og åbne spørgsmål
- Anbefaling til scope for build-fasen
- Engagement-form (fast / månedlig / hybrid)
- Klar go/no-go beslutning
- 02Fase 02 · Build
Vi bygger i korte iterationer med deploy fra dag ét.
Vi sætter op fra mandag i uge 1: repo, CI/CD, preview-environment, observability. Hver pull request får sit eget preview-link, så I kan teste features før de merger. Hver fredag er der en demo — kort, konkret, intet teater. Tilpasninger og prioritering sker løbende, ikke i en stor change-request-runde for enden af en sprint.
- Production-stack klar fra dag 1
- Preview-deploy på hver PR
- Ugentlige fredagsdemoer (15–30 min)
- Slack/Teams-kanal med direkte adgang
- Code review og dokumentation løbende
- Vi siger til hvis noget bør prioriteres om
- 03Fase 03 · Drift
Vi overdrager noget der kan drives — eller bliver hængende.
Når I er live, har I tre veje: vi overdrager fuldt ud (med runbooks, observability, incident-procedurer og vores telefonnummer i en periode), vi tager et fast drifts-engagement med oppetidsmål og response-tider, eller en kombination hvor vi løbende videreudvikler men jeres team ejer driften. Det aftales i Discovery — ikke som en overraskelse til sidst.
- Runbooks der er auditerbare
- Observability og alerting på vej
- Incident response-procedure
- Dokumentation jeres team kan onboarde på
- Overdragelses-workshops til jeres udviklere
- Aftalt SLA hvis vi tager driften videre
Det vi tror på
Seks beslutninger vi tager hver gang.
Det her er ikke regler. Det er valg vi konsistent træffer, fordi vi har set hvad alternativet koster.
Små teams over store
Et lille team der kender hele systemet leverer mere end et stort team der kender hver sin del. Vi sætter typisk 2–3 mennesker på et engagement, ikke 6.
Ende-til-ende ejerskab
Den der designer dataflowet sætter også monitoreringen op. Det fjerner overdragelsesgab, og det betyder at den der bygger en feature også står ved den når den fejler kl. 02.
Deploy fra dag ét
En staging-URL skal eksistere fra første uge. Det tvinger valg om miljøer, secrets, CI og observability tidligt — og giver dig noget at klikke på, ikke en Figma-skitse.
Forsvarlige valg over moderne valg
Vi bruger Postgres frem for det nyeste databasevendor, Next.js frem for det nyeste meta-framework. Modent og kedeligt slår nyt og spændende, når noget skal stå oppe i fem år.
Dokumentation undervejs, ikke til sidst
READMEs, ADR'er (architectural decision records) og runbooks skrives mens vi bygger — ikke efter. Det betyder at de faktisk eksisterer når vi forlader projektet.
Sig fra når det ikke passer
Hvis et engagement begynder at trække i en retning vi ikke kan stå inde for, siger vi det. Bedre at justere scope tidligt end at levere noget hverken vi eller I er stolte af.
Sådan kommunikerer vi
Få faste mødepunkter, masser af direkte adgang.
Ugentlig demo (15–30 min)
Hver fredag viser vi hvad der er kommet i denne uge, hvad der er låst op, og hvad næste uge kigger på. Optaget hvis I ikke kan være med live, så I kan se det asynkront.
Delt Slack/Teams-kanal
I kan skrive direkte til den der har bygget tingen — ikke en account manager der skal videreformidle. Vi svarer indenfor en arbejdsdag, oftest hurtigere.
Preview-link på hver PR
Hver pull request får et preview-environment med en unik URL. I kan teste, kommentere og godkende før vi merger til main.
Async demoer på korte cyklusser
Mellem fredagsdemoerne sender vi korte Loom/CleanShot-optagelser når noget er klar. Bedre end et planlagt møde for noget der tager 90 sekunder at vise.
Månedlig retrospektiv
Én gang om måneden tager vi 30 minutter til at se på hvad der virker, hvad der ikke gør, og om scope eller cadence skal justeres. Vi vil hellere fange friktion tidligt end pænt.
Praktiske spørgsmål
Det vi får spurgt om før vi starter.
Skal vi have en kravspecifikation klar før vi taler?
Nej. Discovery-fasen er netop til at finde den sammen. Hvis I har en eksisterende spec, læser vi gerne den, men vi forventer ofte at den ændrer sig undervejs — det er sundt. Det vi har brug for fra start er en fornemmelse af problem, brugere og constraints. Resten finder vi sammen.
Hvad sker der hvis I bliver syge eller forsvinder midt i et projekt?
Vi arbejder i små, dedikerede teams (typisk 2–3), og alt vi bygger er i jeres repo, jeres infrastruktur, jeres dokumentation. Hvis der sker noget, kan I fortsætte med et andet team uden at miste kontrollen. Vi anbefaler også et fast handover-vindue ved aftalens ophør — det er en del af Drift-fasen.
Hvor agile er I egentlig? Følger I Scrum?
Vi følger ikke en bestemt metodologi til punkt og prikke. Korte iterationer, ugentlige demoer, preview-deploys, retrospektiver — ja. Story points, ceremonier-for-ceremoniens-skyld og burn-down-charts som kunden skal kigge på — nej. Hvis jeres team kører Scrum og vil have os ind i det rul, justerer vi.
Hvor meget skal vores eget team være involveret?
Mindst én forretnings-side beslutningstager skal være tilgængelig på Slack og til ugentlige demoer. Hvis I har egne udviklere der skal videreføre, er det godt at have dem med fra dag 1 så de er fortrolige med kodebasen ved overdragelse. Andet er valgfrit — vi kan også køre et engagement helt selvstændigt.
Hvad hvis vi vil ændre scope undervejs?
Forventet. Vi arbejder med rullende prioritering snarere end fastlåste sprints. Større scope-ændringer (en ny feature på størrelse med dem vi allerede har planlagt) tager vi en separat samtale om — de fleste mindre justeringer ryger bare ind i næste uges plan.
Hvor ligger jeres faktiske team?
Vi sidder på Sjælland og er bevidst remote-først i selve byggeforløbet. Discovery foregår gerne fysisk hvis I er i nærheden — og vi kommer gerne ud til større demoer og kickoffs. Selve udviklingen kører bedst remote med vores stack.
Klar når I er
Lad os tale om hvordan det her ville se ud for jer.
30 minutter, uforpligtende. Vi vurderer ærligt om vi er det rigtige team, og hvad et realistisk første skridt er.