Programvarekategoriene som mest sannsynlig vil bli bygget in-house innen 2027

Innen 2027 er programvarekategoriene som mest sannsynlig vil bli bygget internt arbeidsflytautomatisering, interne adminverktøy, dashbord og BI-rapportering, enkle CRM-systemer, prosjektledelse og verktøy for kundestøtte. Skillelinjen går mellom prosess og korrekthet. Programvare som koder hvordan virksomheten din fungerer, er nå billigere å bygge enn å leie. Programvare som må være korrekt hver eneste gang, som lønn, betalinger, hovedbøker og skatt, vil forbli kjøpt.

Hvilke programvarekategorier går over til internt først?

Arbeidsflyt- og adminverktøy går først. Retools 2026 Build vs. Buy-rapport spurte 817 utviklere og fant at 35 % allerede hadde erstattet minst ett SaaS-verktøy med en tilpasset løsning, og 78 % planla å bygge mer i 2026. Kategoriene under størst press for utskifting: arbeidsflytautomatisering (35 %), interne adminverktøy (33 %), BI-verktøy (29 %), CRM- og skjemaverktøy (25 %), prosjektledelse (23 %) og kundestøtte (21 %).

Se på hva disse kategoriene har til felles. De flytter dine egne data gjennom din egen prosess. Ingen av dem involverer komplisert informatikk; verdien var alltid arbeidsflyten, og arbeidsflyten er din, ikke leverandørens. Når et generisk verktøy dekker 70 % av prosessen din og tar betalt per bruker for privilegiet, begynner en AI-assistert løsning som dekker 100 % å vinne i regnearket. Kostnaden ved å feile er også lav. Et ødelagt internt dashbord koster deg en ettermiddag, ikke et søksmål.

Hvorfor skjer dette nå?

Agentbasert koding forvandlet "det burde vi bygge en dag" til en todagers jobb. Gartner forutser at innen 2027 vil over 65 % av ingeniørteam som bruker agentbasert koding anse IDE-er som valgfrie, der kontroll, styring og validering flyttes til automatiserte plattformer. Å bygge programvare er i ferd med å bli noe du overvåker i stedet for noe du taster inn.

Den samme Retool-undersøkelsen viser hvordan moden AI-bygging ser ut i praksis. Blant utviklere som leverte fungerende programvare, bruker 72 % AI til å skrive avgrensede deler av koden som de integrerer selv, bare 31 % prompter seg frem til komplette apper, og kun 8 % leverer AI-generert kode uten endringer. Prompt-til-app er fortsatt mindretallsveien. Det som har endret seg, er at kostnaden for tilpasset programvare falt nok til å snu standardvalget mellom å bygge eller kjøpe for en hel klasse med verktøy. Det skjedde i det stille også: 60 % av de spurte utviklerne leverte noe utenfor IT-avdelingens tilsyn det siste året.

Hva beviste Klarna egentlig?

Klarna beviste skillet, ikke hypen. I 2024 kunngjorde administrerende direktør at selskapet la ned Salesforce og Workday, og overskriftene erklærte slutten på SaaS. Oppfølgingsrapportene var mer nyttige enn overskriftene: CX Today bekreftet at Klarna erstattet Workday med en annen leverandørs HR-plattform og gjenoppbygde sin CRM-funksjonalitet fra en blanding av mindre SaaS-verktøy og egenutviklet lim, med AI lagt på toppen.

Les det nøye, og det bekrefter kategorilisten ovenfor. Det Klarna bygde internt, var bindevevet: datakonsolidering, intern arbeidsflyt, laget der prosessen deres er unik. Det de ikke gjorde, var å vibe-kode en kjernebankbok. Klarna er en lisensiert bank. Programvaren som må være korrekt hver gang, forble hos spesialister, mens prosessprogramvaren flyttet internt, og det er den samme avveiningen de fleste selskaper vil gjøre innen 2027.

Hvilken programvare vil forbli kjøpt?

Alt der et feil svar koster penger eller en lisens. Lønns- og skattemotorer. Regnskapssystemer. Betalingsbehandling og PCI-samsvar. Sertifisert maskinvare for fysisk betaling. Lagerbeholdning under samtidig belastning, der to kasser selger den siste enheten i samme sekund og antallet likevel må bli riktig. Rapporter som stemmer på øret.

AI skriver denne typen kode flytende og selvsikkert, noe som er akkurat problemet. Flytende og selvsikker er ikke det samme som korrekt under belastning, revidert og sertifisert, og disse egenskapene kommer fra år med produksjonstrafikk og samsvarsarbeid som ingen kodingsagent kan komprimere. Undersøk enhver "AI bygde hele stacken vår"-historie nøye, og du vil finne en kjøpt kjerne under.

Hvor lander en POS i dette skillet?

En POS befinner seg på begge sider av linjen samtidig, noe som gjør den til et nyttig testtilfelle. Forsiden av en POS, altså betalingsflyten, skjermene, hva som skjer etter et salg, og hvordan de ansatte håndterer en bestilling, er prosessprogramvare: samme art som de interne verktøyene som flyttes internt overalt ellers. Det er derfor etterspørselen etter en tilpasset POS fortsetter å vokse. Forhandlere er ferdige med å tilpasse arbeidsflyten i kassen etter en leverandørs mal. Under det laget ligger oppgjør, lagerbeholdning og avstemt rapportering, som lander trygt i kategorien for programvare som forblir kjøpt.

Det farbare mønsteret for 2027 er å bygge laget du har sterke meninger om på toppen av en infrastruktur som noen andre sørger for at er korrekt. Final er bygget rundt dette skillet: du beskriver din POS i vanlig språk, eller kobler til din egen AI over MCP, og flytene du oppretter kjører på administrert handelsinfrastruktur, der lagerbeholdning, rapportering og Final Pay håndterer betalinger gjennom en betalingsformidler og sertifiserte terminaler. For å se mønsteret i praksis viser gjennomgangen av hvordan du bygger en tilpasset POS med ChatGPT-5.6 nøyaktig hvor AI-en gjør jobben og hvor infrastrukturen tar over.