Hur AI har förändrat min build-vs-buy-kalkyl

Förr var min build-vs-buy-fråga ganska traditionell: hur lång tid tar det att bygga, vad kostar leverantören, hur mycket underhåll får vi själva och hur strategisk är funktionen? AI har inte gjort den modellen irrelevant. Den har flyttat flera av gränserna.

Saker som tidigare krävde ett specialiserat team kan nu prototypas mycket snabbare. Samtidigt har det blivit lättare att underskatta drift, kvalitetssäkring och det som händer efter första demon. Resultatet är att jag bygger mer själv än tidigare – men inte nödvändigtvis mer av allt. Det bredare beslutsramverket för att bygga eller köpa en AI-lösning har jag gått igenom separat; här handlar det specifikt om hur själva kalkylen har förskjutits.

AI pressar ned kostnaden för första 70 procenten

En stor förändring är hur snabbt man kan få fram en fungerande vertikal skiva. Kodassistenter, generering av boilerplate, testförslag, SQL, dokumentation och UI-komponenter gör att en liten personstyrka kan komma mycket längre.

Det förändrar kalkylen för verktyg där leverantörens främsta moat tidigare var utvecklingskapacitet.

Men de sista procenten är ofta där produktkostnaden flyttar tillbaka in:

• edge cases,
• auth och permissions,
• migrations,
• observability,
• betalningar,
• support,
• säkerhet,
• dokumentation,
• tillförlitliga integrationer,
• uppgraderingar.

Jag räknar därför inte "jag kan bygga en demo på två dagar" som bevis för att buy-alternativet är dyrt.

Jag delar upp beslutet i commodity och differentiator

En användbar fråga är: ger den här komponenten oss en unik fördel, eller behöver den bara fungera?

Betalningsinfrastruktur är ett tydligt exempel på något jag normalt hellre köper än bygger. Samma sak gäller ofta autentisering, mail delivery och grundläggande observability. De är kritiska men sällan där min produktdifferentiering ligger.

Däremot kan själva matchningslogiken i en CV-produkt, ett evidence workflow för content eller en egen analysmotor vara centralt för hur produkten skiljer sig.

Min tumregel är ungefär:

Det är inte absolut, men det ger en bättre start än "kan AI skriva koden?".

Vendor lock-in har bytt form

Tidigare tänkte jag mest på databaser, proprietära API:er och exportmöjligheter. Nu behöver jag också tänka på hur mycket av produktbeteendet som sitter i en specifik modell eller leverantörsfunktion.

Om prompten, verktygen och datamodellen är tätt bundna till en leverantör kan ett modellbyte bli dyrt även om API-formatet ser enkelt ut.

Därför försöker jag hålla domänregler, states och evals utanför modellen. Då kan jag testa en annan modell mot samma kontrakt i stället för att bygga om produkten från noll.

Evals har blivit en del av inköpskriteriet

När jag jämför en extern AI-tjänst med att bygga själv vill jag inte bara jämföra featurelistor. Jag vill veta om jag kan mäta kvaliteten på mitt faktiska jobb.

Kan jag exportera data? Kan jag se loggar? Kan jag testa egna cases? Kan jag styra eller verifiera modellbeteendet? Går det att skilja på promptfel, toolfel och modellfel?

Anthropic rekommenderar att man börjar med den enklaste arkitekturen som fungerar och bara lägger till mer agentisk komplexitet när den mätbart förbättrar resultatet. Jag tycker samma princip fungerar för build-vs-buy: köp gärna en abstraktion, men inte om abstraktionen gör den viktigaste kvaliteten omätbar. Anthropic: Building Effective Agents

TCO för AI är mer än tokenkostnad

Tokenpris är lätt att räkna och därför lätt att överbetona. Den verkliga kostnaden kan också ligga i:

• mänsklig review,
• failed runs,
• support,
• latency,
• retries,
• dataförberedelse,
• evals,
• prompt- och modellmigrationer,
• compliance,
• vendorarbete.

Ett billigt API kan bli dyrt om varje tredje output kräver manuell korrigering. En dyrare färdig produkt kan vara billig om den eliminerar mycket operativt arbete. Och en egen lösning kan vara billigast om jobbet är smalt, stabilt och nära vår egen data.

Jag försöker därför tänka i kostnad per godkänd uppgift, inte kostnad per API-anrop.

Buy vinner när problemet redan är löst bättre än jag behöver

Jag bygger inte för att bygga. Om en standardtjänst löser problemet, har bra export, rimlig prissättning och inte tar kontroll över en strategisk del av produkten är buy ofta rationellt.

AI gör det lätt att bli övermodig eftersom mycket kod går snabbare. Men kodvolym är inte samma sak som ägandekostnad.

Jag skulle exempelvis hellre köpa robust betalning än skapa min egen betalstack bara för att en coding agent kan generera mycket av koden. Samma sak gäller ofta e-postleverans, hosting primitives och andra väl lösta infrastrukturlager.

Build vinner oftare när problemet är smalt och domänspecifikt

AI har däremot gjort små specialverktyg mer attraktiva att bygga.

Om jag har:

• tydlig data,
• ett smalt workflow,
• konkreta regler,
• ett eval-set,
• låg integrationsbörda,
• starkt behov av egen kontroll,

kan egen utveckling vara mycket billigare än förr.

Det gäller särskilt när en SaaS-leverantör säljer ett brett paket men jag egentligen behöver tio procent av funktionerna och vill att de tio procenten ska fungera exakt på mitt sätt.

Min beslutsmatris idag

Jag brukar väga sex dimensioner:

AI flyttar framför allt tids- och utvecklingskolumnerna. Den tar inte bort de andra fyra.

Slutsatsen är inte "bygg mer"

Min kalkyl har blivit mer offensiv kring små, strategiska verktyg och mer konservativ kring infrastruktur.

Jag bygger gärna ett eget workflow som uttrycker hur jag vill att ett problem ska lösas. Jag köper gärna komponenterna runt omkring som andra redan har gjort till commodity.

AI har alltså inte avskaffat build-vs-buy. Den har gjort det viktigare att veta vilken del av värdekedjan man faktiskt vill äga.

Relaterade artiklar

• Hur jag går från idé till fungerande AI-produkt
• Varför jag inte började med MCP i alla mina projekt
• Skill vs system prompt vs agent: vad ska användas när?
• Vad jag lärt mig från att bygga flera små SaaS-produkter med AI
• Varför jag börjar med workflow innan jag väljer modell