Platform Engineering – bygga eller köpa en IDP?

Platform engineering har etablerat sig som nästa logiska steg efter DevOps. När era utvecklingsteam växer från ett till flera uppstår samma mönster om och om igen: varje team uppfinner sin egen väg till produktion, sina egna mallar, sin egen övervakning. En Internal Developer Platform, eller IDP, är svaret på den fragmenteringen. Frågan som varje CTO och teknisk ledare ställer sig 2026 är inte om ni behöver en plattform, utan om ni ska bygga den själva eller köpa en färdig.

Den här artikeln ger er en ärlig TCO-jämförelse och ett ramverk för att avgöra var ni står. Jag har varit med om båda vägarna inom DevOps-plattform, och svaret är olika för olika bolag. Det viktiga är att fatta beslutet medvetet, inte att drivas av trend.

Vad en IDP faktiskt är – och inte är

En IDP är inte ett verktyg ni installerar. Det är en produkt ni bygger för era utvecklare, med målet att göra det enkelt att göra rätt. Den samlar er infrastruktur, era deployment-flöden, er övervakning och era säkerhetsregler bakom ett gemensamt gränssnitt, så att ett team kan komma igång med en ny tjänst på timmar i stället för veckor.

Kärnkomponenterna i en modern IDP är tre: en tjänstekatalog som visar vad som körs, vilka som äger det och hur det mår; golden paths, det vill säga fördefinierade, väldokumenterade vägar för att skapa, deploya och övervaka en tjänst; och självbetjäning så att teamen själva kan begära resurser utan att skapa en manuell beställning till plattformsteamet.

Alternativet att köpa: Backstage, Port och Cortex

Marknaden för färdiga IDP-plattformar har mognat snabbt. De tre stora alternativen 2026 är Backstage (öppen källkod från Spotify, nu under CNCF), Port och Cortex. Alla tre löser kärnproblemet med en tjänstekatalog och golden paths, men de skiljer sig i hur mycket ni måste bygga själva och hur de prissätts.

• Backstage är öppet och flexibelt. Ingen licenskostnad, men ni bygger och driftar allt själva. För en organisation med ett dedikerat plattformsteam är det svårslaget i anpassningsbarhet. Den totala ägandekostnaden landar ofta på €150K-250K per år om ni räknar in utvecklingstiden.
• Port är en hanterad produkt med fokus på snabb tid till värde. Ni konfigurerar er katalog och självbetjäning i ett gränssnitt i stället för att skriva kod. Priset ligger på €200K-350K per år beroende på antal team och användare.
• Cortex betonar scorecards och tjänstemognad, vilket passar organisationer som systematiskt vill höja kvaliteten i en spretig tjänsteflora. Prisbilden liknar Ports: €200K-450K per år.

Alternativet att bygga: total kontroll till ett högre pris

Att bygga en egen IDP från grunden, ofta med Backstage som ramverk eller med egna komponenter, ger maximal kontroll. Ni bestämmer exakt vad tjänstekatalogen visar, hur golden paths ser ut och hur integrationerna mot era specifika verktyg fungerar. För ett bolag med mycket speciella krav eller en unik tech stack kan det vara enda vägen.

Priset är dubbelt. Dels den initiala utvecklingskostnaden på €1,2M-2,5M för en fullt fungerande plattform med ett par tjänstetyper och golden paths. Dels den löpande förvaltningen: ett team på två till fyra personer som underhåller, uppgraderar och vidareutvecklar plattformen. På tre års sikt blir den egna plattformen sällan billigare än en köpt, om inte volymen är mycket stor – över 30-40 team och 200+ tjänster.

När bygga – och när köpa?

Min erfarenhet efter att ha sett båda vägarna är att de flesta bolag överskattar hur unika deras behov är. En köpt plattform med rätt konfiguration täcker 80-90% av behoven för de flesta organisationer. Bygg gör att ni får de sista 10-20% perfekta, men ni betalar för det med en hel plattformsorganisation.

• Köp om ni har 3-20 team och vill ha värde inom kvartalet. Ni kommer igång snabbt och kan fokusera er utvecklingskapacitet på affären.
• Bygg om ni har 30+ team, mycket speciella säkerhets- eller compliancekrav, eller om er tech stack är så unik att inget färdigt verktyg passar.
• Hybrid om ni är i mitten: bygg er första golden path med Backstage och en enkel catalog-as-code-lösning, och utvärdera om ni vill växla till en hanterad plattform när behoven växer.

Vanliga misstag jag ser

Det absolut vanligaste är att börja bygga en plattform innan behovet finns. En plattform som ingen använder är bortkastade pengar, oavsett hur snygg den är. Börja i stället med att identifiera den mest återkommande smärtan i era team – ofta är det "det tar för lång tid att sätta upp en ny tjänst" – och bygg eller konfigurera en enda golden path som löser just det. När den används och uppskattas, bygg ut därifrån.

Ett annat vanligt misstag är att underskatta förvaltningen. En IDP är inte ett projekt med ett slut. Den är en produkt som måste underhållas precis som er huvudprodukt. Utan ett dedikerat ägandeskap förfaller den, och teamen slutar lita på den. Hur jag tänker kring hela plattformsresan beskriver jag i min tjänst för DevOps-plattform.

Relaterat

• Platform Engineering 2026: Backstage vs Port vs Cortex
• Kubernetes för 5-personers team: När det är värt komplexiteten
• Infrastructure as Code: Terraform + Atlantis + policy as code

Vill du se hur en IDP-resa sett ut i praktiken finns exempel i min casebook.

Vill du ta det vidare?

Jag hjälper svenska bolag att navigera bygga-vs-köpa-beslutet för Internal Developer Platforms – oberoende rådgivning utan leverantörsbindning. Boka ett samtal så går vi igenom era team, er tech stack och er budget.