skal vi bygge eller købe?
det klassiske svar passer ikke længere. det nye svar er ikke det du tror.
ai og no-code har ændret regnestykket for altid. men ikke på den måde de fleste tror. resultatet er at mange virksomheder nu bygger ting de skulle have købt. og køber ting de skulle have bygget.
det gamle regnestykke
indtil for to år siden var svaret ret simpelt. saas-leverandøren havde et udviklingshold på 50 til 500 mennesker. din virksomhed havde måske en halv. de kunne bygge produktet billigere end dig, vedligeholde det bedre end dig, og opdatere det hurtigere end dig. så med mindre du var netflix eller byggede dit produkts kerne-ip, købte du.
den logik holder stadig i bunden. men kanten har flyttet sig markant.
det er blevet nemmere at bygge. det er problemet.
hurtigere udvikling med ai-assistenter (github, 2024)
af store custom software-projekter bliver opgivet
af custom softwares levetidsomkostninger er vedligeholdelse
kilder: github copilot research, standish group chaos 2024, cisq
værktøjer som claude code, lovable og n8n har sænket barren for hvem der kan bygge hvad. en beslutningstager uden udvikler-baggrund kan i dag bygge en prototype på en eftermiddag, som for tre år siden havde krævet et sprint og et budget.
det er den her udvikling der gør siden farlig i 2026. fordi i praksis ser vi to fejl gentage sig.
de der bygger ting de skal købe. prototypen virker. den løser 70 procent af problemet. så begynder den reelle liste: authentication, gdpr-compliance, backup, versionering, onboarding-flows, support. 70 procent blev til et vedligeholdelsesprojekt for en person der egentlig skulle arbejde med noget andet.
de der køber ting de skal bygge. leverandøren matcher 80 procent af behovet. der forhandles om de sidste 20 procent. det bliver en integration, så et customization-projekt, så tre år med at presse forretningens unikke logik ind i en standardløsning. custom-builds fejler i 35 procent af tilfældene. men customiserede saas-løsninger fejler ikke sjældnere, de bliver bare sværere at gøre op med.
"det er ikke blevet lettere at bygge. det er blevet lettere at bygge noget der ligner en løsning. forskellen er afgørende."
det rigtige spørgsmål
den klassiske test "er det core eller commodity?" er stadig brugbar, men ikke præcis nok i 2026. det mere nyttige spørgsmål er tredelt.
unikhed
hvor tæt ligger løsningen på jeres unikke arbejdsgang? hvis en leverandør har bygget den samme løsning 500 gange før, er det commodity. hvis jeres arbejdsgang ser anderledes ud end 9 ud af 10 konkurrenter, er det værd at overveje selv.
femårsregnestykket
hvad er de samlede omkostninger over fem år, ikke i måned et? 60 til 80 procent af custom-software-omkostninger ligger i vedligeholdelse. samtidig kan saas-omkostninger vokse 3 til 5 gange når i tilføjer brugere, integrationer eller datamængde.
risiko-ejerskab
hvem bærer ansvaret når tingene bryder sammen? en intern build betyder at i bærer risikoen selv. saas betyder at i er afhængige af en leverandørs roadmap. der er ikke noget rigtigt svar, der er et rigtigt svar for jeres situation.
hvornår det virkelig giver mening at bygge
vi lavede for nyligt en kommerciel diagnose for en virksomhed, hvor det klassiske svar ville have været at købe. markedet havde en løsning. den dækkede 80 procent af behovet. prisen så fornuftig ud på papiret.
men da vi regnede de samlede omkostninger igennem, og tog stilling til hvor præcist systemet skulle ramme arbejdsgangen, blev billedet et andet. en skræddersyet løsning, bygget på moderne ai-værktøjer, kunne løse 100 procent af behovet til en brøkdel af den femårige saas-pris.
det er casen vi udgiver her om kort tid. den vigtige pointe: i de fleste tilfælde er det modsatte sandt. det er kun i de få, hvor regnestykket for alvor vælter, at det giver mening at bygge.
hvornår giver det mening at tale med os
vi sælger ikke udviklingstimer og er ikke certificeret i en bestemt platform. det betyder at vi ikke har en skjult interesse i at anbefale det ene frem for det andet.
i har fået et tilbud på at bygge noget selv og vil stresse det før i siger ja
i har et saas-setup der ikke rigtig rammer plet og overvejer om bygge-sporet er et alternativ i dag
i har en intern udvikler eller et bureau der meget gerne vil bygge, og i er ikke sikre på om det er det rigtige
i er lige begyndt at stille spørgsmålet og vil have hjælp til at formulere det rigtige regnestykke
vi siger ofte nej til at bygge, også når det er godt for vores egen timeseddel. det er hele pointen med en uafhængig kommerciel arkitekt.
fortæl os hvad i overvejer at bygge eller købe
så laver vi regnestykket sammen. en halv times sparring, ingen forudsætninger.