Beslutningsguide
Next.js er blevet standardsvaret når danske teams skal bygge SaaS, kundeportaler eller marketing-sites der både skal rangere og føles hurtige. Det er også blevet et buzzword. Resultatet: mange får tilbud på "et Next.js-site" uden at nogen har afklaret om det er den rigtige model — eller det rigtige hold.
Det her er hvordan vi tænker på valget mellem in-house, freelancer og et Next.js-bureau. Ikke som en pitch for os selv, men som den samtale vi typisk har i discovery før nogen skriver en linje kode.
TL;DR
De vigtigste pointer
- Hyre et Next.js-bureau når I mangler production-erfaring i stacken, har en deadline, eller skal eje et produkt der skal drives — ikke bare leveres.
- Bliv in-house når I allerede har folk der har shippet Next.js til produktion, og produktet er kerne-IP I vil holde tæt.
- En freelancer er ofte rigtig til en skarp, afgrænset leverance. Den bliver dyr når scope glider og ingen ejer drift, SEO og release-hygiejne.
- Det I køber hos et godt bureau er ikke "flere hænder" — det er beslutninger: rendering-strategi, auth, data-isolation, caching og hvordan I release uden at knække sitet.
- Spørg altid: hvem ejer koden, hosting, DNS, analytics og den ugentlige release efter go-live? Hvis svaret er uklart, er setup'et forkert.
Hvorfor Next.js overhovedet er samtalen
Next.js kombinerer det teams typisk vil have samtidigt: server-renderet HTML til SEO og first paint, React til komplekse UI'er, og en deploy-model der passer til Vercel, Cloudflare eller jeres egen Node-host. Det er derfor både marketing-sites og fulde SaaS-produkter ender i samme framework.
Men frameworket løser ikke produktbeslutningerne. Skal siden være statisk, ISR eller dynamisk? Hvor ligger auth? Hvordan isolerer I tenants? Hvad caches på edge, og hvad må aldrig caches? Det er de spørgsmål der adskiller et site der føles hurtigt i tre måneder fra et der stadig er til at arbejde med om tre år.
Et Next.js-bureau der er værd at hyre, taler mere om de beslutninger end om komponentbiblioteker. Hvis samtalen starter med designsystemer og ender uden et ord om rendering, observability eller release, så køber I sandsynligvis UI — ikke et produkt.
In-house vs. Next.js-bureau — i praksis
In-house / egen kapacitet
Bedst når stacken allerede er jeres, og I kan holde tempo uden ekstern afhængighed.
- IP og kontekst bliver i virksomheden
- Prioritering følger jeres roadmap direkte
- Kræver folk der har shippet Next.js til produktion — ikke kun tutorials
- Drift, SEO og incident-response skal også dækkes in-house
- Langsommere opstart hvis I skal rekruttere eller oplære først
- Risiko for "learning in production" på den første rigtige app
Next.js-bureau
Bedst når I skal have tempo, production-defaults og et hold der har set fejltilstandene før.
- Hurtigere fra beslutning til første preview-deploy
- Defaults for auth, caching, forms, SEO og observability følger med
- I køber beslutningskraft — ikke kun implementeringstid
- Kræver en tydelig ejerskabsmodel efter go-live
- Dårligt match hvis I kun vil have piksel-perfekt UI uden produktansvar
- Fungerer bedst med en intern produkt-ejer der kan sige ja/nej ugentligt
Hvornår hvad — en konkret matrix
Brug den her når I står mellem "vi klarer det selv", "vi finder en freelancer" og "vi hyre et bureau".
Bliv in-house / freelancer
I har allerede Next.js i produktion og folk der har drifttet det
Hyre et Next.js-bureau
In-house — brug ekstern hjælp til spidsbelastning, ikke til kernebeslutninger
Bliv in-house / freelancer
I skal have et MVP eller relaunch inden for en fast horisont
Hyre et Next.js-bureau
Bureau — tempo og færdige defaults slår oplæring midt i et sprint
Bliv in-house / freelancer
Opgaven er en afgrænset landingsside uden auth eller kompleks data
Hyre et Next.js-bureau
Freelancer eller in-house — hold det småt
Bliv in-house / freelancer
I bygger multi-tenant SaaS, kundeportal eller noget med betalinger
Hyre et Next.js-bureau
Bureau eller meget stærkt in-house — fejl her er dyre at rulle tilbage
Bliv in-house / freelancer
SEO, Core Web Vitals og preview-deploys er en del af succeskriteriet
Hyre et Next.js-bureau
Bureau der bygger til crawl og performance fra dag ét — ikke "vi fikser SEO senere"
Bliv in-house / freelancer
I vil eje koden 100% og kunne skifte leverandør
Hyre et Next.js-bureau
Begge modeller kan — kræv repo, CI og infra i jeres konti fra start
“Det dyre er sjældent timerne. Det dyre er at opdage for sent at rendering, auth eller data-model blev valgt forkert.”
Hvad et godt Next.js-bureau faktisk leverer
Et seriøst engagement starter ikke med Figma-til-kode. Det starter med scope: hvilke sider er offentlige, hvilke er autentificerede, hvilke data må caches, og hvad er definitionen på "færdig" for første release. Uden det ender I med et smukt UI oven på en uklar backend.
Derefter kommer stack-defaults. For de fleste forretningsprodukter betyder det Postgres, server-side auth, typed API-grænser, preview-miljøer på hver pull request, og en deploy-pipeline I kan forstå. Next.js er rammeværket — resten er det der gør produktet driftsklart.
Til sidst: overdragelse. I skal kunne pege på repoet, hosting-kontoen, domænet, analytics og den person (intern eller ekstern) der tager telefonen når noget fejler en fredag. Hvis bureauet "hoster det hele for jer" uden at I har nøglerne, har I købt en afhængighed — ikke et produkt.
Spørgsmål I bør stille et Next.js-bureau
Hvis svarene er uklare, er det et signal — uanset hvor flot portfolien ser ud.
- Hvem ejer GitHub-repo, Vercel/Cloudflare-konto, DNS og databasen efter go-live?
- Hvordan vælger I mellem static, ISR og dynamisk rendering på vores sidetyper?
- Hvordan håndterer I auth, roller og (hvis relevant) multi-tenant isolation?
- Får vi preview-URL på hver pull request, og hvem approve'r releases?
- Hvad er jeres plan for Core Web Vitals, sitemap, canonicals og hreflang?
- Hvordan ser de første 90 dages drift ud — hvem monitorerer, og hvordan eskalerer vi?
- Kan vi fortsætte in-house senere uden at omskrive halvdelen af sitet?
En fornuftig måde at starte samarbejdet på
Uanset om I vælger os eller en anden — den her sekvens sparer uger.
- 01
Discovery på problemet — ikke på UI
Afklar brugere, auth, data, SEO-krav og hvad "done" er for v1. Tegn hellere flows end mockups i første uge.
- 02
Vælg rendering og hosting før komponentbibliotek
Beslut hvad der er statisk, hvad der er dynamisk, og hvor det deployer. UI-kit kan skiftes. En forkert data-model kan ikke.
- 03
Første preview tidligt
Få en deployet URL op hurtigt — gerne inden for de første iterationer — så I reagerer på noget rigtigt, ikke på slides.
- 04
Skriv ejerskab ind i aftalen
Repo, miljøer, secrets og domæne i jeres konti. Bureauet arbejder derinde. Det gør exit og in-house overtagelse mulig.
- 05
Planlæg drift før launch
Aftal monitoring, backup, hvem der retter fejl, og hvordan I shipper ændringer efter go-live. Launch uden drift er kun halvdelen.
Spørgsmål vi får igen og igen
Hvad laver et Next.js-bureau anderledes end et klassisk webureau?
Et klassisk webbureau optimerer ofte for designleverance og CMS-sider. Et Next.js-bureau (der mener det alvorligt) optimerer for app-lignende produkter: server rendering, auth, API'er, preview-miljøer og performance under rigtig trafik. I skal høre ord som ISR, edge caching, migrations og observability — ikke kun "responsivt design" og "WordPress-tema".
Kan vi starte med et bureau og tage over in-house senere?
Ja — hvis aftalen er bygget til det. Kræv at kode, CI, hosting og dokumentation ligger hos jer fra dag ét, og at stacken er almindelig nok til at en intern udvikler kan fortsætte. Vi arbejder bevidst sådan: målet er at I kan overtage, ikke at I er låst.
Er Next.js kun til marketing-sites?
Nej. Next.js bruges til både marketing-sites, kundeportaler og fulde SaaS-produkter. Forskellen er rendering-strategi og backend-tyngde — ikke frameworket. Et marketing-site kan være næsten statisk; en SaaS har auth, roller og hyppige dataopdateringer. Samme værktøj, forskellige defaults.
Hvor langt er et typisk Next.js-MVP?
Et fokuseret MVP ligger typisk i størrelsesordenen 8–14 uger, afhængigt af auth, integrationer og hvor skarpt scope er. Det er proces-tid — ikke et løfte om jeres konkrete projekt. Det der sprænger tidslinjen er næsten altid uklare krav midtvejs, ikke selve Next.js.
Skal vi vælge Vercel hvis vi vælger Next.js?
Nej, men det er ofte den laveste friktion for teams der vil have preview-deploys og edge uden at bygge platformen selv. Cloudflare, containere og klassisk Node-hosting er også mulige. Valget bør følge jeres driftkrav, compliance og eksisterende cloud — ikke et dogme.
Hvis I er midt i beslutningen
Tag en uforpligtende snak om setup — før I vælger hold.
Vi hjælper gerne med at afklare om in-house, freelancer eller bureau er det rigtige til jeres Next.js-projekt. I får en ærlig vurdering, også hvis svaret er at I skal vente eller bygge selv.