Byg vs. køb vs. AI i produktudvikling

Vi er nu mere end halvvejs gennem 2026. AI-værktøjer og LLM'er er ikke længere bare kodeassistenter; de er aktive deltagere (på godt og ondt) i vores udviklingslivscyklus. Virksomheder kæmper for at tilpasse deres SDLC'er til at indarbejde brugen af LLM'er. Nogle integrerer AI, mens de fastholder strenge software engineering best practices. Andre bruger AI som en løftestang til aggressivt at reducere antallet af ansatte og satser på, at produktivitetsgevinsterne opvejer risiciene.

Dette er ikke en artikel om de reelle eller opfattede fordele ved AI-hypen. Nogle gevinster er reelle, men det er de forsinkede effekter også.

I stedet vil jeg genbesøge det gamle spørgsmål om "byg vs. køb" i AI'ens tidsalder. Den udbredte opfattelse er, at AI har brudt denne binære opdeling. Jeg vil argumentere for, at AI ikke har brudt den. Den har bare gjort det forkerte valg billigere at træffe og dyrere at rette.

Det eneste spørgsmål, der betyder noget

For fem år siden var spørgsmålet simpelt.

Er den nye feature en kernedifferentiator for din virksomhed?

• Ja -> byg den. Du har brug for fuld kontrol over produkt-roadmappet
• Nej -> køb den.

Auth, betalinger, monitorering, hændelseshåndtering. Dine ingeniører kunne sikkert bygge det hele. Det er ikke spørgsmålet. Spørgsmålet er, om det at bygge det tjener penge til dig, eller om det bare holder dig travl. Oftest er det det sidste.

Og hver time brugt på en ikke-kernefeature er en time, der ikke er brugt på det, der rent faktisk tjener penge til dig. Det er den reelle omkostning, ikke sprint-estimatet.

Regningen kommer senere

Selv med AI ser det billigt ud at bygge på dag ét. Det er det ikke.

Cirka 60-80% af et systems levetidsomkostninger falder efter lancering. Vedligeholdelse, vagtplaner, patching, kl. 2-om-natten-hændelsen. De fleste teams tager fejl her, ikke fordi de er dårlige til estimater, men fordi "vi kunne bygge det her på en uge" kun tæller ugen.

Med AI forstærkes denne illusion. En AI-agent kan skitsere et CRM-system på en eftermiddag. Men hvem patcher sikkerhedssårbarhederne i den AI-genererede kode? Hvem sikrer, at det overholder GDPR, når reglerne ændrer sig i 2027? Har vi teamet til at drive det om tre år, eller har vi bare bygget en digital landmine?

Køb har også sine fejl

At købe er ikke et gratis frikort. Det er et andet sæt risici, ikke nul risiko.

• Leverandørrisiko: Leverandøren bliver opkøbt, prisen tredobles ved fornyelse, eller den feature, du har bygget din arbejdsgang omkring, bliver udfaset i en changelog, som ingen læser.
• "AI-skatten": Mange leverandører skifter fra flad SaaS-prissætning til forbrugsbaseret prissætning. Det gør det svært at budgettere. Du kan ikke længere forudsige regningen, som du kunne med en licens til 50 USD/måned.
• Compliance-gevinster: Omvendt giver det for alt, der berører reguleret data (HIPAA, PCI, SOC 2), ofte umiddelbare compliance-certificeringer ved at købe, som du ellers skulle tjene dig til på den hårde måde. Dette alene kan nogle gange afgøre beslutningen.

At købe bytter "hvem patcher det" ud med "hvem ringer vi til."

AI-as-a-Service vs. interne AI-teams

Ud over byg og køb er der en tredje mulighed, der opstod i AI-boomet fra 2024-2026: at bygge interne AI-teams.

Mange virksomheder skyndte sig at ansætte prompt-ingeniører, finjustere modeller og bygge tilpassede RAG-pipelines i troen på, at dette ville skabe en konkurrencemæssig voldgrav. I 2026 er lektien klar: for de fleste ikke-AI-native virksomheder er det at bygge en intern AI-stack en "kontekst"-fælde.

• At bygge et internt AI-team: Du er nu i business med at håndtere modeldrift, GPU-omkostninger og prompt-sikkerhed. Det er svært, dyrt og sjældent en differentiator.
• At købe AI-kapabiliteter: Brug specialiserede AI-SaaS-værktøjer (f.eks. AI-drevet juridisk gennemgang, AI-drevet kundesupport), der allerede løser de svære problemer med modelvalg og compliance.

Jeg siger ikke "byg aldrig." Der er tilfælde, hvor det er den rette beslutning at bygge AI-infrastruktur:

• Du er en AI-virksomhed: Hvis din model er dit produkt, er det ikke til forhandling at bygge den internt.
• Du har proprietær data, der ikke må forlade dit netværk: Sundhedssektoren, forsvar og visse finansielle institutioner kan simpelthen ikke sende følsomme data til tredjeparts-API'er.
• Din skala gør per-API-prissætning uholdbar: I massiv skala kan forbrugsbaseret prissætning fra leverandører overstige omkostningen ved et internt team - men kun hvis du allerede har bevist product-market fit.

Hvis intet af dette gælder for dig, overtænker du det sandsynligvis. Køb AI-kapaciteten. Byg ikke AI-infrastrukturen.

Hvad AI faktisk ændrede

Hastighed... Det er hele listen.

Tiden til at lave en prototype gik fra uger til dage, nogle gange minutter. Og cirka 65% af de mennesker, der nu shipper AI-assisteret kode, kommer ikke fra en udviklerbaggrund. De sidder i drift, marketing, økonomi osv.

Så ja, en marketingpraktikant kan nu shippe et fungerende CRM på en weekend. Det er kraftfuldt. Det er også skræmmende, og det besvarer ikke spørgsmålet: bør de?

Men i stedet for at fokusere på om vi bør, fokuserer teams på om vi kan. Og det er dér, det går galt.

Ja, du kunne bygge din egen version af PagerDuty. Én uge, grundlæggende funktionalitet, færdig. Men nu har du bygget dit eget hændelseshåndteringssystem. Hvem driver det? Hvem patcher det? Hvem er på vagt, når det går ned klokken 3 om natten? Noget af det kan agent-loops nu håndtere, ja. Men agenter er også tilbøjelige til hallucination, rate limits og kaskadefejl.

Hvad AI ikke ændrede

SaaS-prissætningen forsvinder ikke, bare fordi koden blev shippet hurtigere.

I nogle tilfælde blev det værre. Nogle leverandører (måske endda dig selv) tilføjer en "AI-skat" på enterprise-fornyelser eller skifter til forbrugsbaseret prissætning. Det betyder, at du ikke længere kan forudsige regningen på købersiden, som flad SaaS-prissætning tillod. Nogen skal bære omkostningen ved AI-token-budgettet, og lige nu videresender de fleste virksomheder den direkte til kunden. Ikke fordi der ikke er andre muligheder, men fordi gevinsterne - hvad enten det er fra selve AI-værktøjerne eller fra det antal ansatte, de har kunnet skære (uanset om det er en god eller dårlig beslutning) - endnu ikke er slået igennem på bundlinjen.

Så ja, det blev hurtigere at bygge, men i de fleste tilfælde sværere at prissætte.

Mange virksomheder lander på en hybrid tilgang: køb råvaren, byg differentieringen ovenpå. Køb Stripe-abonnementet, og byg beslutningsmotoren, der sidder oven på det.

Nogle ting forbliver et klart køb, AI eller ej: multi-tenant infrastruktur som AWS eller Stripe, hvor den operationelle skala ikke kan replikeres. Adgang til frontier-modeller eller at jagte prompt-drift internt er et tabt spil. Netværkseffekt-platforme som Slack eller Figma, hvor værdien er grafen af andre brugere, ikke featuresættet.

Det ene reelle skift

Den ene reelle forandring, AI bragte, er ikke teknisk. Det er governance.

Med drift, marketing og økonomi, der nu shipper software uden for IT's synsfelt, holdt spørgsmålet op med at være "kan vi bygge det?" og blev til "kan vi governe det, der allerede er bygget?"

Det er et sværere job, end gatekeeping nogensinde var. Du kan ikke gennemgå hver eneste AI-genererede PR. Du kan ikke manuelt auditere hver linje kode, der shippes af en ikke-udvikler. Det, du kan gøre, er at etablere autoværn: sikkerhedsscanning, omkostningsovervågning, compliance-tjek og klart ejerskab.

Governance handler ikke om at sige nej. Det handler om at sikre, at når tingene går i stykker - og det vil de - så ved du, hvem der ejer rettelsen.

Resultatet ændrede sig ikke

AI omskrev ikke byg vs. køb. Den gjorde bare fejlen billigere at shippe og dyrere at opdage.

Det eneste spørgsmål, der betyder noget, er stadig det samme, som det altid har været: er dette kerne, eller er det kontekst? Alt andet - hastigheden, ikke-udviklerne der shipper kode, AI-skatten, forbrugsprissætningen - er blot støj omkring den samme beslutning. Besvar det, før prototypen lanceres.

De teams, der vinder, bliver ikke dem, der bygger mest. De bliver dem, der bygger de rigtige ting og køber alt andet, før AI-skatten vokser sig for stor.

Start med spørgsmålet. Besvar det. Så byg.