Bygga eller köpa enterprise-mjukvara: Det leverantörsneutrala ramverket (med 12-punkts poängrubrik, 2026)
Förra september ställde en kund med $50M ARR oss en fråga som kostar företag miljoner att svara fel på: stanna på ett Salesforce + Tableau + Outreach-paket värt $487K under de kommande fem åren, eller bygga en egenutvecklad revenue ops-plattform för $312K? Det "billigare" svaret var fel. Här är ramverket vi använde för att räkna ut det: en 12-punkts poängrubrik, en 5-årig TCO-modell och Gartners köp/bygg/kombinera-trichotomi som ingen av de tio bästa bygga-eller-köpa-guiderna på Google ens nämner. Och ja, vi är en ingenjörsbyrå, så vi talar om för dig när du bör köpa SaaS istället för att anlita oss.
Viktiga slutsatser (TL;DR):
- De flesta bygga-eller-köpa-råd kommer från leverantörer som tjänar på ett av svaren. Ta reda på källans bias innan du litar på dem.
- Gartners köp/bygg/kombinera-ramverk täcker nu 76% av enterprise-mjukvaruutgifterna. Rent byggande eller rent köpande är undantaget 2026.
- Poängsätt ditt beslut på 12 viktade kriterier, inte magkänsla. Egenutveckling vinner när totalen är >45; SaaS vinner under 30.
- AI-kodningsagenter (Cursor, Claude Code) sänkte senior ingenjörstimmar per funktion med 40–60% 2026. Matematiken för att bygga har förändrats.
Vad är beslutet att bygga eller köpa enterprise-mjukvara?
Beslutet att bygga eller köpa handlar om att välja mellan att licensiera befintlig SaaS- eller COTS-mjukvara (köpa), att utveckla egenutvecklad mjukvara internt (bygga) eller att anlita en partner-byrå för att bygga proprietär mjukvara (samarbeta). Gartners moderna formulering utvidgar detta till köp/bygg/kombinera, och 76% av enterprise-mjukvaruutgifterna flödar nu in i kombinationer av standardprodukter och anpassade tillägg, inte rent byggande eller rent köpande.
Beslutet hänger på tre frågor:
- Är förmågan en konkurrensfördel eller en standardprodukt?
- Vad är den sanna 5-åriga TCO för varje väg?
- Kan du bemanna ett senior ingenjörsteam som äger det på lång sikt?
Heads-up: Techsy är en ingenjörsbyrå. Vi tjänar pengar när du bygger. Så vi tänker berätta om alla fall där du bör köpa SaaS istället och inte anlita oss, för på lång sikt fungerar poster som denna bara om matematiken är ärlig. Vi har nämnt vårt konverteringsmål längst ner; allt däremellan är ramverket, inte säljargumentet.
De flesta bygga-eller-köpa-guider är skrivna av folk som tjänar på ett av de två svaren. SaaS-marknadsplatser vill att du ska köpa. Dev-byråer vill att du ska bygga. COTS-leverantörer vill att du ska göra vad som helst som skyddar deras förnyelse. Läs tre av dem och du får tre säkra, motsatta rekommendationer, var och en begravd under en säljkrok. Om du specifikt utvärderar ett AI-röstbygge har vi skrivit en vertikal version av detta ramverk som kör samma logik på ett snävare beslut. Resten av detta inlägg är det allmänna upphandlingsramverket du faktiskt kan köra på ett möte.
Vad Gartner faktiskt säger: köp/bygg/kombinera-ramverket
Gartners upphandlingsramverk avvisar den binära bygga-eller-köpa-frågan och ersätter den med ett trevägs beslut: köp (licensiera COTS eller SaaS), bygg (intern egenutveckling) eller kombinera (kombinera SaaS för standardarbetsflöden med egenutvecklad kod för differentierade arbetsflöden). Enligt Gartners köp/bygg/kombinera-modell flödar 76% av enterprise-mjukvaruutgifterna nu in i kombinerade stackar. Rent byggande eller rent köpande är undantaget.
Köp = Licensiera det som är standardiserat
Köp när förmågan är ett löst problem och någon annan redan har lanserat lösningen i stor skala. CRM, löner, e-post, utläggshantering, observabilitet. Ekonomin för att köpa är bäst när du har <100 användare på arbetsflödet, behöver det live om <90 dagar och SaaS löser mer än 80% av ditt behov direkt ur lådan.
Bygg = Äg det som differentierar dig
Bygg när förmågan är ditt skyddsgravar. Det som kunder köper dig för. Stripe licensierade inte en betalningsstack. Figma licensierade inte en renderingsmotor. Byggande vinner också när SaaS bokstavligen inte kan modellera din datastruktur (tänk komplex flerentigetsfinansiering eller ovanliga regelefterlevnadsregimer) eller när din 5-åriga SaaS-räkning i skala överstiger TCO för egenutveckling med 2 gånger eller mer.
Kombinera = Det matematiken de flesta företag faktiskt landar på
Att kombinera innebär att du behåller COTS för de tråkiga 80% och bygger anpassat för de differentierade 20%. Det klassiska mönstret: Salesforce som registreringssystem + ett tunt anpassat lager för de arbetsflöden Salesforce inte kan modellera rent. Thoughtworks kallar detta köp/bygg/samarbeta; Gartner kallar det köp/bygg/kombinera. Samma idé, lite annorlunda vokabulär. Trichotomins rötter går tillbaka till McKinseys tillverka-eller-köpa-matris från 1990-talet, men molnera gjorde det tredje alternativet dominerande.
| Väg | Tid till värde | Uppstartskostnad | Löpande kostnad | Ägarskap | Leverantörsrisk |
|---|---|---|---|---|---|
| Köp (SaaS) | Dagar till veckor | Låg | Hög, förutsägbar | Lågt | Hög |
| Bygg (egenutvecklat) | 4–12 månader | Hög | Medel, variabel | Fullt | Ingen |
| Kombinera | Veckor till månader | Medel | Medel | Partiellt | Medel |
12-punkts poängrubriken (kopiera in i ett kalkylblad)
Poängsätt varje kriterium 1–5 baserat på hur starkt det gäller din situation. Multiplicera med vikten. Addera totalerna. Tröskellegenden längst ner berättar vilken väg matematiken pekar mot. Använd detta på ett verkligt upphandlingsmöte och du skär ner debatten från två timmar till tjugo minuter.
| # | Kriterium | Vad det betyder | Vikt | Poäng (1–5) |
|---|---|---|---|---|
| 1 | Konkurrensfördel | Är den här förmågan en kärndel av varför kunder köper dig? | ×3 | __ |
| 2 | Senior ingenjörsstyrka | Kan ditt team realistiskt äga det i 5+ år? | ×2 | __ |
| 3 | Problemets nyhet | Är problemet nytt (5) eller välförstått (1)? | ×1 | __ |
| 4 | Time-to-market-brådska | Är det kritiskt att leverera på <6 månader? Lägre = mer brådskande | ×2 | __ |
| 5 | SaaS-täckningslucka | Löser ingen befintlig SaaS >80% av ditt behov? | ×2 | __ |
| 6 | Tolerans för inlåsning | Kan du leva med leverantörsprishöjningar och roadmap-risk? Lägre = mindre tolerant | ×1 | __ |
| 7 | 5-årig SaaS TCO i skala | Kommer SaaS-kostnaden att överstiga egenutvecklad TCO under 5 år? | ×2 | __ |
| 8 | Dataunikhet | Har din data en struktur som SaaS inte kan modellera? | ×1 | __ |
| 9 | Regelefterlevnad / dataresidens | Finns det begränsningar som utesluter stora SaaS-leverantörer? | ×1 | __ |
| 10 | AI-kostnadsminskning vid byggande | Kommer AI-kodningsagenter att minska din byggkostnad jämfört med 2023? | ×2 | __ |
| 11 | Integrationskomplexitet | Är integrationen till omgivande system redan tung? | ×1 | __ |
| 12 | IP-värdeinsamling | Skapar byggandet proprietär IP som höjer företagets värdering? | ×1 | __ |
Tröskellegend:
- Totalt <30 → Köp SaaS
- Totalt 30–45 → Kombinera
- Totalt >45 → Bygg
Genomarbetat exempel, med vår fallstudiekund (den vi går igenom i detalj i avsnittet om fallstudien): de fick poängen 38. Konkurrensfördelar var 3 (revenue ops är viktigt men inte deras skyddsgrav), styrka var 2 (de kunde inte dedikera ingenjörer på lång sikt), SaaS-täckningslucka var 4 (Salesforce missade ungefär en tredjedel av deras arbetsflöden), AI-kostnadsminskning var 5. Netto: solitt i Kombinera-territoriet, vilket är där rekommendationen landade.
En varning. Poängrubriken är ett beslutsstöd, inte en beslutsfattare. Om din poäng är gränsland (28–32 eller 43–47) kör TCO-modellen i nästa avsnitt innan du förbinder dig. Siffror ändrar kalkylen.
TCO-modellering: Hur du ärligt beräknar 5-årskostnaden
Enligt Gartner-forskning om programvarukostnadsanalys missar företag 50–70% av TCO vid beräkning av mjukvaruägande. De mest missade posterna: integration, admin-heltidsekvivalenter och flyktkostnad. Prislapppen för år 1 är den minsta delen av räkningen, och nästan varje leverantörsdemo ger dig exakt det numret.
Så här beräknar du 5-årig TCO ärligt för varje väg.
Köp (SaaS) poster: licensiering × användare × år, implementering och installation, utbildning, admin-heltidsekvivalentallokeringen (vanligtvis 0,5–2 heltidsekvivalenter i enterprise-skala), integration till befintliga system och flyktkostnad när du så småningom migrerar bort.
Bygg (egenutvecklat) poster: ingenjörsarbete initialt (ingenjörsmånader × fullt belastad kostnad), underhåll per år (branschens tumregel: 15–20% av initial byggkostnad), infrastruktur och verktyg och alternativkostnaden för den ingenjörskapacitet du förbinder dig till.
Kombinera poster: SaaS-prenumerationen för det standardiserade lagret, plus den anpassade integrations-/tilläggskostnaden, plus underhållet för det anpassade lagret. Lägre uppfront än fullt byggande, lägre löpande än fullt köpande.
Använd $230K som en fullt belastad US-kustkostnaden för en ingenjör: BLS median var $130 160 i maj 2024, lägg sedan till ~30% för förmåner och ~25% för overhead. Justera ±30% för din geografi. Europeiska team kör vanligtvis 20–30% lägre; icke-kust-US-team 15–20% lägre.
| Kostnadskategori | Köp (SaaS) | Bygg (egenutvecklat) | Kombinera |
|---|---|---|---|
| År 1 licensiering eller initialt dev | $60K | $230K | $90K |
| Implementering / installation | $40K | inkluderad | $20K |
| År 2–5 löpande licensiering | $240K | $0 | $120K |
| Underhåll @ 15–20%/år | n/a | $35K/år | $15K/år |
| Integration till andra system | $25K | $40K | $30K |
| Admin / ops heltidsekvivalentallokeringen | $80K | $20K | $50K |
| Flykt / migrationskostnad | $40K | n/a | $20K |
| 5-årstotal | $485K | $465K | $390K |
Generiska illustrativa intervall. Dina siffror skiljer sig; kategorierna gör det inte.
När du ska KOMBINERA (mellanalternativet de flesta företag landar på)
Att kombinera vinner när varken rent köpande eller rent byggande kartlägger sig rent mot ditt arbetsflöde. Du behåller COTS för standardiserade lager (CRM, fakturering, identitet, observabilitet) och bygger anpassat för de arbetsflöden som antingen är din konkurrensfördel eller helt enkelt är omöjliga att modellera i SaaS. Limmet mellan dem är API:er, MCP-servrar eller low-code workflow-motorer.
Fyra konkreta kombineringsmönster vi ser upprepade gånger:
- Salesforce + anpassat RevOps-lager. Salesforce stannar som registreringssystem. Det anpassade lagret hanterar de flerstegiga revenue-arbetsflöden som Salesforces processbyggare inte kan modellera rent. Fallstudiekunden nedan är exakt detta mönster.
- SAP/NetSuite + anpassat datalager. Behåll ERP:n för redovisning och inköp. Bygg ett lager + anpassade dashboards för de finansiella analyser din CFO faktiskt vill ha.
- HubSpot + anpassad enrichment-pipeline. Använd HubSpot för sekvensering och CRM men bygg din egen enrichment när kommersiella dataleverantörer inte är tillräckligt exakta på din ICP.
- COTS HR + anpassad arbetsflödesautomation. BambooHR eller Rippling för journalerna, n8n eller anpassad kod för den onboarding + offboarding-orkestrering ingen paketerar bra.
Kombinationen blev avsevärt billigare 2026 eftersom att lägga till AI-funktioner inkrementellt i en befintlig SaaS inte längre kräver ett forskningsteam, och MCP-servrar som låter dig sy ihop SaaS och anpassad kod komprimerar integrationsskatten som historiskt gjort kombinationer dyra. Kombinationen är inte en kompromiss. Det är svaret för 76% av företagen, enligt Gartner.
När du ska BYGGA (3 scenarier där egenutveckling vinner)
Bygga vinner i tre tydliga scenarier. Om inget av dem beskriver din situation bör du förmodligen inte bygga.
1. Förmågan är din konkurrensfördel
Om kunder köper dig för den specifika förmågan kan du inte licensiera den från en leverantör vars övriga kunder är dina konkurrenter. Stripe licensierade inte en betalningsstack. Notion licensierade inte en dokumentmotor. Förmågan måste vara skyddsgraven, inte bara en funktion du råkar använda.
2. SaaS kan inte modellera din unika datastruktur
Om din data har en struktur som befintlig SaaS bokstavligen inte kan representera (komplex flerentigetsfinansiering, ovanliga regulatoriska scheman, realtids-multiplayer-tillstånd) kommer du att spendera mer på anpassningsavgifter och konsulttimmar än du skulle göra på att bygga från grunden. Testa detta genom att be två SaaS-leverantörer göra ett betalt POC. Om båda misslyckas, bygg.
3. 5-årig SaaS TCO överstiger egenutveckling med 2 gånger eller mer
Matematiken vänds vid användning. 500 användare på en $200/seat/mån SaaS = $1,2M/år = $6M under 5 år. En fokuserad egenutveckling för samma arbetsflöde kanske landar på $400K initialt + $80K/år underhåll = $800K under 5 år. När multipeln är 2 gånger eller mer och arbetsflödet är stabilt, bygg.
Ärlig riskvarning: att bygga innebär att du äger projektrisk. Standish Groups CHAOS-rapport visar att 69% av IT-projekt delvis eller helt misslyckas. Att bygga är inte gratis ens när matematiken säger det. Mildra med scopedisciplin, riktigt produktägande och en tidig MVP. För intern AI-tooling specifikt är självhostad enterprise AI-tooling ett byggmönster vi ser fungera 2026 där färdiga alternativ inte uppfyller dataresidens-kraven.
När du ska KÖPA (och de dolda kostnaderna ingen pratar om)
Att köpa vinner när förmågan är standardiserad, du behöver det live snabbt och SaaS löser det mesta av ditt behov direkt ur lådan. Tre scenarier:
1. Förmågan är standardiserad
CRM, e-post, redovisning, observabilitet, identitet, utläggshantering. Det här är lösta problem. SaaS-leverantörerna har levererat tusentals kantfall du annars skulle träffa på själv. Att bygga något av dessa från grunden 2026 är nästan alltid fel.
2. Du behöver det live om <90 dagar
Om arbetsflödet blockerar intäkter och du inte har ingenjörsstyrka att avvara, köp. Alternativkostnaden för ett 6-månaders bygge kontra en 6-veckors SaaS-utrullning överstiger licensavgiften i nästan alla fall.
3. SaaS löser >80% direkt ur lådan
Om anpassningsskulden för de sista 20% kostar mindre än den totala SaaS-premien, köp bara. Testa detta genom att skriva lucklistan innan du skriver på. Om luckorna är arbetsflödeslatta (inställningar, integrationer, lätt rapportering) är du fine. Om de är arbetsflödestyngre är du inte det.
De dolda kostnaderna ingen sätter på demo-bilden:
| Dold kostnad | Vad det är | Typisk skala |
|---|---|---|
| Leverantörsinlåsning | Att byta till en konkurrent tar 6–18 månader | Fördubblar förhandlingsstyrkan vid nästa förnyelse |
| Anpassnings-/ändringsbegäranavgifter | Debiterbara timmar per funktion från leverantören | $200–500/tim, ofta med tak |
| Per-seat-krypning i skala | Licensantal växer med organisationen | 7–15%/år sammansatt |
| Integrationskostnader | Varje koppling du monterar på | $20K–$100K per system |
| Flykt-/migrationskostnad | Att få ut dina data rent | 3–6 månaders ingenjörsarbete |
| Årliga prishöjningar | Förnyelseökningar oavsett användning | 7–15%/år typiskt |
SaaS-prissättning kryper uppåt. Zylos 2025 SaaS Management Index visar att det genomsnittliga företaget slösar ungefär $21M per år på oanvända eller duplicerade SaaS-seats. Licensavgiften är den första kostnaden, inte den totala.
Fallstudie: Vi hjälpte en $50M SaaS-kund att besluta — $487K Salesforce-stack vs $312K egenutveckling
Under Q3 2025 frågade en $50M-ARR B2B SaaS-kund oss om de skulle utöka sin befintliga Salesforce + Tableau + Outreach-stack (beräknad $487K 5-årig TCO) eller bygga en egenutvecklad revenue ops-plattform på Next.js + Postgres + deras egna pipeline-verktyg (beräknad $312K 5-årig TCO). Här är den faktiska post-för-post-matematiken vi gick igenom med dem, varför alternativet med $312K "billigare" var fel för dem, och vad de levererade istället.
Rubrikfrågan såg binär ut: fortsätt betala SaaS-premier eller bygg något billigare. Posterna berättade en annan historia.
| Post | Köp (SaaS-stack) | Bygg (egenutvecklad RevOps) |
|---|---|---|
| Salesforce Sales Cloud Enterprise (60 seats × $165/mån × 5 år, efter förhandling) | $340K | — |
| Tableau Creator (20 seats × $75/mån × 5 år) | $90K | — |
| Outreach.io (40 seats × $120/mån × 5 år) | $288K (listpris) → ~$57K netto inkrementellt | — |
| Admin heltidsekvivalentallokering (1,5 heltidsekvivalenter × 5 år) | inkluderad | — |
| 2 senior ingenjörer ($230K fullt belastad var) × 6 månader initialt | — | $230K |
| 0,5 heltidsekvivalent underhåll × 5 år (vid 15% utnyttjande) | — | $57K |
| Vercel + Neon + Linear infrastruktur (5 år) | — | $30K |
| 5-årstotal | ~$487K | ~$312K |
På pappret vann byggande med $175K. Rekommendationen gick åt andra hållet.
Varför den "billigare" egenutvecklingen var fel för dem: de hade inte en senior ingenjörsstyrka som kunde absorbera 0,5 heltidsekvivalents underhåll på obestämd tid. Ingenjörsorganisationen levererade redan kärnprodukten. Att allokera 10–15% av senior kapacitet till revenue ops-underhåll under de kommande fem åren innebar antingen att sakta ner produktens roadmap eller att anställa (vilket skulle driva den faktiska Bygg TCO förbi $800K när man räknar med faktiska anställningar till marknadspris, inte absorberad kapacitet). Det "billiga" numret antog gratis ingenjörer. Ingenjörer är aldrig gratis.
Vad vi faktiskt levererade: en Kombination. Behåll Salesforce som registreringssystem. Bygg ett tunt anpassat revenue ops-lager ($85K initialt, nästan noll löpande) för de 4 arbetsflöden Salesforce inte kunde modellera rent. Netto 5-årig TCO landade på ~$420K, mellan de två rubriknumren, och de fick de arbetsflöden de faktiskt behövde. Levererat på 11 veckor, inga nya anställningar, ingen roadmap-glidning.
18 månader senare: det anpassade lagret är fortfarande i produktion, Salesforce-förnyelser gick igenom utan drama och ingenjörsteamet behövde inte kontextbyta tillbaka till RevOps-underhåll efter det initiala byggandet. Nettobedömning: Kombinationen var rätt svar för att den respekterade ingenjörsstyrkerastriktionen som Bygg-matematiken hade ignorerat.
Siffror anonymiserade och avrundade per vårt konsultavtal. Kostnader förutsätter 2025–2030 fönster. Salesforce-prissättning återspeglar post-aug-2025 listprishöjningar. Produktivitetsvinster med AI-kodningsagenter (Q3 2025 baslinje) redan inbakade i $312K ingenjörsestimering. Ingenjör fullt belastad till $230K = US-kust-median per BLS 2024 + 30% förmåner + 25% overhead, justera ±30% för din geografi. Vi är en ingenjörsbyrå. Det här var en verklig rekommendation mot vårt eget kommersiella intresse.
Hur AI har förändrat bygga-eller-köpa-matematiken 2026
Crossover-punkten har rört sig. AI-kodningsagenter har komprimerat senior ingenjörstimmar per funktion med 40–60% i våra interna mätningar från kundarbete 2026. Det innebär att en bygguppskattning du körde 2023 nu är väsentligen fel. Gartner förutspår att 75% av enterprise-mjukvaruingenjörer kommer att använda AI-kodassistenter till 2028, upp från 10% 2023, och vår pipeline-data återspeglar redan det mesta av den antagningen före schema.
Tre konkreta skiften:
- 18-månaders egenutvecklingar levereras nu på 6–8 månader när scopen hålls konstant. Kombinationen i fallstudien ovan levererades på 11 veckor; samma scope 2023 skulle ha tagit 18–20 veckor.
- Teamstorlek för interna verktyg har minskat. Vi kör rutinmässigt 2-ingenjörs-pods för byggen som behövde 5 ingenjörer för två år sedan, eftersom AI-kodningsagenter som Cursor och Claude Code absorberar boilerplate-koden som brukade suga upp mellannivåkapacitet.
- Fallstudiekundens $312K-bygguppskattning var ungefär 30% lägre än samma uppskattning skulle ha varit 2023, innan AI-nativ enterprise-mjukvaruutveckling blev standardarbetssättet.
Ärlig motpunkt: AI sänker byggkostnader, men det sänker också kostnaden SaaS-leverantörer betalar för att leverera funktioner. Leverantörspristryck är verkligt, vissa SaaS-priser kommer att gå ner och crossover-punktsskiftet är inte helt ensidigt. Den riktningsenliga effekten gynnar fortfarande byggande (särskilt Kombinera), för intern ingenjörsgenomströmning sammansätts med AI snabbare än leverantörsprissättning gör.
Vanliga beslutsfall (falsk ekonomi, sunk cost, NIH-syndrom, leverantörsoptimism)
Fyra fällor vi ser sabotera beslutet upprepade gånger:
- Falsk ekonomi. Att välja det billigare år 1-numret medan man ignorerar 5-årig TCO. Fallstudien ovan gick nästan åt det hållet. Prislapppen år 1 är den minsta delen av räkningen på varje väg.
- Sunk cost. Att stanna på en SaaS du vuxit ifrån för att migrationen ser dyr ut. Migrationen är vanligtvis billigare än ytterligare 3 år med fel verktyg. Beräkna det.
- NIH (Not Invented Here)-syndromet. Att bygga saker som borde köpas för att ingenjörsteamet tycker problemet är intressant. Ett CRM är inte intressant. En betalningsprocessor är inte intressant. Köp dem.
- Leverantörsoptimism. Att tro att varje rad i leverantörsdemons fungerar i din miljö utan integrationsskatt. Demon är bästa fallet. Ditt fall är svårare. Diskontera demon med 30% innan du jämför.
Det dyraste misstaget vi ser: att välja det billigare år 1-numret och ignorera 5-åriga flyktkostnaden.
Hur Techsy hanterar bygga-eller-köpa-bedömningar
Techsy levererar anpassade enterprise-plattformar, integrerar SaaS i befintliga stackar och gör teknisk due diligence på COTS-utvärderingar för B2B-kunder. Arbetet fördelar sig ungefär 40/30/30 över dessa tre.
En Techsy bygga-eller-köpa-bedömning ser ut så här: ett timmes discovery-samtal för att avgränsa arbetsflödet, vi kör 12-punkts rubrik live med dig på ett delat kalkylblad, vi levererar en TCO-modell inom en vecka och vi skickar en skriftlig rekommendation som kan säga "köp SaaS, anlita inte oss." Våra senaste 3 bedömningar: 1 rekommenderade bygga, 1 rekommenderade köpa, 1 rekommenderade kombinera. Vi har ingen kvot. Om du tänker i större perspektiv om bredare enterprise AI-transformation är bedömningen vanligtvis rätt utgångspunkt. Boka en gratis 30-min bygga-eller-köpa-bedömning.
Vanliga frågor
Vad är skillnaden mellan att bygga, köpa och samarbeta i mjukvara?
Att köpa innebär att licensiera befintlig SaaS eller COTS-mjukvara. Att bygga innebär att utveckla egenutvecklad mjukvara internt med dina egna ingenjörer. Att samarbeta innebär att anlita en byrå eller konsult för att bygga proprietär mjukvara du äger. Gartner omformulerar detta som köp/bygg/kombinera, där kombinera kombinerar licensierad COTS för standardarbetsflöden med egenutvecklad kod för differentierade, vilket nu täcker 76% av enterprise-mjukvaruutgifterna.
När bör du bygga mjukvara istället för att köpa?
Bygg när tre villkor håller: förmågan är en konkurrensfördel kunder köper dig för, du har en senior ingenjörsstyrka som kan äga det i 5+ år utan att sakta ner din roadmap och 5-årig SaaS TCO vid din användarantal överstiger egenutvecklad TCO med minst 2 gånger. Om något av de tre saknas vinner kombinera eller köpa nästan alltid på ärlig matematik.
När är det billigare att köpa SaaS än att bygga egenutvecklad mjukvara under 5 år?
Att köpa vinner på TCO när du har färre än ~100 användare på arbetsflödet, förmågan är standardiserad (CRM, e-post, redovisning, observabilitet) och du behöver det live på under 90 dagar. Under dessa trösklar landar SaaS-prenumerationen, även med årliga prishöjningar, lägre än fullt belastad ingenjörsarbete plus underhåll plus infrastruktur plus alternativkostnad.
Vad säger Gartner om att bygga vs köpa?
Gartner avvisar den binära inramningen och använder en trevägs köp/bygg/kombinera-modell. Deras data visar att 76% av enterprise-mjukvaruutgifterna nu flödar in i kombinerade stackar (licensierad COTS plus anpassade tillägg), inte rent byggande eller rent köpande. Gartner rapporterar också att företag missar 50–70% av den sanna TCO i initiala beräkningar, mestadels på integration, admin-heltidsekvivalentallokering och flyktkostad poster.
Är bygga vs köpa dött?
Den binära inramningen är död. Det trevägs beslutet är det inte. Att kalla frågan "bygga vs köpa" döljer det faktum att de flesta företag landar på att kombinera: SaaS för standardarbetsflöden, anpassat för de differentierade, lim mellan dem. Beslutet är levande och svårare än det ser ut, för nu väljer du uppdelningspunkten, inte en sida. Formulera det som köp/bygg/kombinera och matematiken blir tydligare.
Hur förändrar AI-kodning (Cursor, Claude Code) bygga-eller-köpa-matematiken 2026?
AI-kodningsagenter som Cursor och Claude Code sänkte senior ingenjörstimmar per funktion med 40–60% i våra 2026 mätningar från klientbyggen. Det förflyttar crossover-punkten: byggen som inte gick ihop 2023 gör det nu. Gartner förutspår att 75% av enterprise-mjukvaruingenjörer kommer att använda AI-kodassistenter till 2028, så detta skifte är hållbart, inte tillfälligt. 18-månaders byggen levereras nu rutinmässigt på 6–8 månader.
Vad är den typiska underhållskostnaden för egenutvecklad enterprise-mjukvara per år?
Branschens tumregel är 15–20% av den initiala byggkostnaden per år, löpande. En $300K egenutvecklad plattform bör budgetera $45K–$60K årligen för underhåll (buggfixar, beroendeuppdateringar, säkerhetspatchar, små förbättringar). Detta exkluderar större funktionsarbete, som behandlas som nytt byggande. Att underbudgetera underhåll är det vanligaste misstaget i egenutvecklad TCO-modellering.
Vilka är de dolda kostnaderna med att köpa enterprise SaaS?
De sex dolda kostnaderna som de flesta demos hoppar över: leverantörsinlåsning (6–18 månader att byta), anpassnings- och ändringsbegäranavgifter ($200–500/tim), per-seat-krypning med 7–15% per år när din organisation växer, integrationskostnader ($20K–$100K per anslutet system), flykt och migrationskostnad (3–6 ingenjörsmånader) och årliga prishöjningar med 7–15% oavsett användning. Licensavgiften för år 1 är sällan mer än 30–40% av den sanna 5-årskostnaden.
Vad är total ägandekostnad (TCO) för mjukvara?
TCO är den fullständiga 5-årskostnaden för en mjukvaruväg inklusive licensiering eller utveckling, implementering, utbildning, integration, löpande underhåll, admin-heltidsekvivalentallokering, alternativkostnad och flykt-/migrationskostnad när du så småningom lämnar. Gartner-forskning visar att företag typiskt missar 50–70% av den sanna TCO i initiala beräkningar. Beräkna det innan du förbinder dig, inte efter.
Hur stort måste ett företag vara för att motivera att bygga egenutvecklad enterprise-mjukvara?
Grov tumregel: ~$10M+ ARR eller ~50+ användare på det specifika arbetsflödet. Under den tröskeln vinner SaaS-prenumerationen nästan alltid för att du inte kan amortera ingenjörsarbete och underhåll över tillräcklig användning. Ovanför den börjar matematiken gynna byggande eller kombinera, särskilt när arbetsflödet är centralt för din konkurrensposition. AI-kodningsagenter 2026 tryckte ner den tröskeln med 20–30% jämfört med 2023 baslinjen.
Om författaren
Mert Batur är medgrundare av Techsy.io, där teamet levererar AI-agenter, automationssystem och röst-/SDR-pipelines för B2B-kunder. Han skriver om det LLM-toolingstack som Techsy-teamet faktiskt använder i produktion. Medgrundare, Techsy.io. Anslut på LinkedIn.
Avslutning
Om du minns en sak från det här inlägget: ta reda på bias hos varje ramverk du läser innan du litar på rekommendationen. Leverantörer ger leverantörsråd. Byråer ger byråråd. Din CFO ger CFO-råd. Läs tre, hitta överlappet och lita på det.
- Kör 12-punkts rubrik live på ett möte. Det skär ner debatten från två timmar till tjugo minuter.
- Beräkna 5-årig TCO ärligt. Prislapppen år 1 är aldrig svaret.
- Standardisera till Kombinera om din poäng landar 30–45. De flesta företag hamnar här ändå.
Om du vill ha ett andra par ögon på beslutet, boka en gratis 30-min bygga-eller-köpa-bedömning. Vi talar om för dig att köpa SaaS om det är rätt beslut. Det har hänt. Det kommer att hända igen.