CRAFTORY
Tilbage til journal
Håndværk·10. maj 2026·6 min

Ét menneske, ejet stack — fordele og begrænsninger ved solo bureau

Solo-bureau lyder som mindre kapacitet og højere risiko. I praksis er det ofte det modsatte. Her er hvad du får — og hvad du IKKE får — når du vælger en ene-mands-virksomhed til dit projekt.

Skrevet af Adrian Sinclair
Ét menneske, ejet stack — fordele og begrænsninger ved solo bureau — cover

"Hvad sker der hvis du bliver syg?" Det er det første spørgsmål jeg får når en kunde overvejer Craftory frem for et større bureau. Det er en fair bekymring — men det er også symptomatisk for hvordan vi tænker om risiko i vores branche.

Lad mig være ærlig om hvad du får og IKKE får når du vælger en ene-mands-bureau som Craftory.

Det du får

1. Direkte adgang til den der bygger

Når du sender en mail, læser den jeg den. Når du har spørgsmål, svarer jeg. Når noget ændrer sig i scopet, beslutter vi det sammen — ikke gennem en account manager der skal "konsultere med teamet".

For tekniske projekter er det værdifuldt. Du behøver ikke forklare dit problem 3 gange (først til sælgeren, så til projektlederen, så til udvikleren). Du taler direkte med personen der løser det.

2. Konsistens i kvalitet

Når én person bygger alt, er kvaliteten konsistent. Der er ingen forskel på "hvem fik den dag de byggede dette". Hver linje kode, hver designvalg, hver beslutning er truffet af samme person med samme standarder.

I et bureau med 8 udviklere kan kvaliteten variere markant fra projekt til projekt afhængigt af hvem der byggede det.

3. Ingen overhead-kostnader i prisen

Et bureau med 8 ansatte skal dække husleje, lønninger, marketing, og administration. Det går oven i prisen for dit projekt. En solo-bureau har ingen af de omkostninger — så mere af dine penge går til selve arbejdet.

For et 80K-projekt: hos et bureau går måske 30K til reelt arbejde. Hos en solo-bureau går 65K til reelt arbejde.

4. Beslutninger sker hurtigt

Hvis du vil ændre noget, behøver jeg ikke have et møde med 4 mennesker først. Jeg vurderer, beslutter, og giver dig svar inden for 24 timer.

For projekter med kort time-to-market er det værdifuldt. Bureau-bureaukrati kan tilføje uger til timeline.

5. Ejerskab og ansvar

Når noget går galt, kan jeg ikke pege på et team-medlem. Det er mit ansvar. Det betyder jeg har stærk incentive til at gøre det rigtigt fra start, og rette det hurtigt hvis noget bryder.

I et bureau diffuses ansvar — det er svært at finde "den der byggede det" når problemer opstår 6 måneder senere.

Det du IKKE får

Lad mig være lige så ærlig om begrænsningerne:

1. Begrænset kapacitet

Jeg kan håndtere 2-4 projekter samtidig. Hvis du har et stort projekt med deadline om 4 uger og kræver 3 udviklere parallelt, så er jeg ikke det rette valg.

Et bureau med 8 udviklere kan smide flere ressourcer på et projekt og levere hurtigere — hvis det er det du har brug for.

2. Ingen 24/7 support

Hvis du har en mission-critical site der absolut ikke må gå ned (medicinsk e-commerce, finansielle services), så har du brug for 24/7 monitoring + on-call rotation. Det kan jeg ikke levere som solo-virksomhed.

For 95% af projekter er det ikke nødvendigt. Men for 5%, er det.

3. Ingen specialist-roller

Et bureau har dedicerede roller: designer, frontend-udvikler, backend-udvikler, DevOps, projektleder, copywriter, SEO-specialist. Jeg er en generalist der dækker det hele rimeligt godt.

For projekter der kræver dyb specialisering i én disciplin (fx avanceret 3D-rendering, real-time multiplayer-spil, financial trading-systemer), er bureau med specialister bedre.

4. Single point of failure

Hvis jeg bliver syg, går på ferie, eller får en personlig krise, så kan jeg ikke arbejde på dit projekt i den periode. Bureauer har redundans — andre folk kan tage over.

For projekter med strenge tidslinjer er dette en reel risiko du skal vurdere.

5. Bus factor af 1

Hvis jeg dør i morgen, sidder du med kode jeg har bygget men ikke har dokumenteret godt nok. Et større bureau har vidensspredning — flere folk kender koden.

Vi mitigerer det ved at: (a) holde kodebase ren og dokumenteret, (b) give kunden adgang til repo + dokumentation, (c) bruge standard tools og frameworks så enhver senior-udvikler kan tage over.

Hvordan jeg håndterer begrænsningerne

Konkret hvad jeg gør for at minimere de risici:

  • Maksimum 4 aktive klient-projekter — så jeg ikke overcommitter
  • Klare scope-låste kontrakter med byggetid på 1-3 måneder
  • Vedligeholdelses-aftaler med klare SLA'er (jeg lover ikke 24/7, jeg lover hverdage 9-17)
  • Backup-aftaler med 2 trustede kollegaer der kan tage over hvis jeg er væk i længere tid
  • Komplet dokumentation så kunden kan få en anden udvikler ind hvis nødvendigt
  • Ingen vendor lock-in — kunden ejer kode, repo, og infrastruktur

Hvornår solo-bureau er det rigtige valg

Vælg solo hvis:

  • Du har et projekt på 50K-300K (sweet spot)
  • Du værdsætter direkte kommunikation over mødeskaber
  • Du vil eje din kode og infrastruktur 100%
  • Du har tålmodighed til en 1-3 måneders timeline
  • Du vil arbejde med samme person i 1-3 år (ikke skifte teams)

Hvornår bureau er det rigtige valg

Vælg bureau hvis:

  • Du har et projekt over 500K der kræver flere parallelle teams
  • Du har brug for 24/7 support eller mission-critical SLA
  • Du har behov for specialiserede roller (DevOps, performance-engineer, security-auditor)
  • Du har en stram deadline der kræver flere folk samtidig
  • Du har budget til at betale for redundans og struktur

Min anbefaling

For 80% af danske SMB-projekter er solo-bureau eller mindre boutique det rigtige valg. Du får mere håndværk per krone, hurtigere kommunikation, og direkte adgang til den der bygger.

For 20% af projekter (enterprise, mission-critical, multi-team) er et bureau bedre.

Hvis du står med valget: book en uforpligtende scope-snak — jeg siger ærligt om vi er det rigtige match til dit projekt eller ej.

Læs videre

— Journal

Få nye artikler direkte i indbakken

1-2 mails om måneden. Ingen spam. Frameld dig når som helst.

— Vil du tale om det?

Skal vi bygge sammen?

20 minutter, ingen forpligtelse. Vi finder ud af om der er match.