skal vi bygge eller købe?

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.

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 her de fleste oplevelses- og medlemsforretninger ender. en standardplatform har en generisk datamodel, og så skal sæsonkort, medlemskab og sponsor bøjes ind i noget der aldrig er lavet til dem.

"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.

svaret er sjældent enten eller

i praksis lander de fleste et tredje sted. du køber de lag der er commodity, billetsystem, betalingsløsning, mailplatform, og bygger kun det tynde lag der binder dem sammen til ét billede af kunden. det er som regel både billigere og mindre risikabelt end begge yderpunkter, fordi du kun ejer vedligeholdelsen af den del ingen leverandør kan sælge dig.

der findes også en fjerde vej, hvor en løsning bygges til én kunde og gøres tilgængelig for flere. den deler udviklingsomkostningen uden at gå på kompromis med datamodellen. den er ikke relevant for alle, men den bør være med i regnestykket.

hvornår det virkelig giver mening at bygge

vi regnede for nylig et setup igennem for en kunde, 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.

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.

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.