Hur vet vi om något är vår konkurrensfördel eller bara en stödfunktion?

Fråga om era kunder betalar för just den funktionen, eller om den bara måste finnas och fungera i bakgrunden. Lönehantering och fakturering är nästan alltid stödfunktioner. Den arbetsprocess eller algoritm som gör er snabbare eller bättre än konkurrenterna är nästan alltid en konkurrensfördel som är värd att bygga och äga själva.

Vad kostar det egentligen att bygga en intern lösning över tid?

Räkna med 600 000–900 000 kronor för en första fungerande version med två utvecklare på sex månader, och därefter 15–25 procent av den kostnaden per år i löpande förvaltning, säkerhetsuppdateringar och vidareutveckling. Över fem år hamnar totalkostnaden ofta dubbelt så högt som den ursprungliga byggkalkylen visade.

Är det farligt att bli beroende av en SaaS-leverantör?

Inlåsningsrisk är verklig men ofta överskattad jämfört med kostnaden att bygga och underhålla samma funktion själv. Bedöm risken konkret: hur svårt är det att exportera er data, finns det etablerade alternativ att byta till, och hur kritisk är funktionen för er verksamhet. En nykter riskbedömning slår principiell rädsla för inlåsning nästan alltid.

Vad gör vi om beslutet är nära 50/50 i poängmodellen?

Ett jämnt utfall är ofta ett tecken på att beslutet är för viktigt för att avgöras på magkänsla internt. Det är exakt de fallen där en oberoende second opinion från någon utan säljagenda ger mest värde – granskningen kostar en bråkdel av vad ett felaktigt tvåårigt byggprojekt gör.

Kan vi byta håll senare om vi väljer fel från början?

Ja, men det är dyrare än att välja rätt från start, särskilt för datatunga kärnkomponenter. Att migrera bort från en etablerad intern lösning eller en djupt integrerad SaaS-produkt efter tre år är ett separat projekt i sig – räkna med att det kostar minst lika mycket som det ursprungliga bygget eller den ursprungliga integrationen.

Bygga vs köpa – en teknisk beslutsmodell

En praktisk beslutsmodell för att avgöra om ni ska bygga en lösning själva eller köpa den färdig – med fyra viktade faktorer, en poängmodell och konkreta exempel på när svenska bolag gått fel åt båda hållen.

”Ska vi bygga det här själva, eller köpa en färdig lösning?” Jag får frågan i nästan varje rådgivningsuppdrag jag tar, och det förvånande är hur sällan den ställs strukturerat. Oftast landar beslutet i magkänsla – en utvecklare som helst vill bygga något eget, en säljare som lovat mer än plattformen klarar, eller en budget som redan är låst innan frågan ens diskuterats ordentligt. Jag har sett bolag lägga två år och sju siffror på att bygga ett internt CRM som en SaaS-lösning för 2 000 kronor i månaden hade löst lika bra. Jag har lika ofta sett bolag köpa in ett standard-ERP för sin kärnverksamhet och sedan spendera tre år på att tvinga in sin unika affärsmodell i någon annans mallar.

Den här artikeln är beslutsmodellen jag faktiskt använder i rådgivningsuppdrag: fyra faktorer som vägs mot varandra, en enkel poängmodell och de vanligaste fallgroparna på båda sidor. Målet är inte ett universellt svar – det finns inget sådant – utan ett strukturerat sätt att komma fram till rätt svar för er specifika situation.

Frågan är fel ställd – börja med värde, inte pris

Det vanligaste misstaget är att ställa frågan som en ren kostnadsjämförelse: vad kostar det att bygga jämfört med en licens? Det är fel utgångspunkt eftersom det ignorerar den viktigaste variabeln – strategiskt värde. En lösning som är billigare att bygga men som inte är er kärnverksamhet är ändå fel beslut, för den binder upp utvecklingskapacitet som borde gå till det som faktiskt differentierar er mot konkurrenterna.

Rätt fråga är: är det här något era kunder betalar för, eller något som bara måste fungera i bakgrunden? Lönehantering, fakturering, kalenderbokning och grundläggande CRM är sällan konkurrensfördelar – de är hygienfunktioner som redan är lösta bättre och billigare av specialiserade leverantörer. Er unika algoritm, ert kärnerbjudande eller den arbetsprocess som gör er snabbare än konkurrenterna är motsatsen: det är sällan meningsfullt att köpa in den från någon annan, eftersom ingen annan har byggt exakt det ni behöver.

De fyra faktorerna som faktiskt avgör beslutet

I varje granskning jag gör väger jag fyra faktorer mot varandra. Ingen av dem är tillräcklig ensam – det är kombinationen som avgör.

Strategiskt värde. Är det här er konkurrensfördel, eller en stödfunktion som måste finnas men inte får kosta uppmärksamhet?
Tid till värde. När behöver lösningen vara i drift, och vad kostar väntetiden om ni bygger själva?
Total ägandekostnad. Vad kostar det att förvalta, säkra och vidareutveckla lösningen de kommande tre till fem åren – inte bara att bygga den?
Flexibilitet och unikhet. Hur ovanliga är era krav? Ju mer standardiserat problemet är, desto starkare talar det för att köpa.

Vår rekommendation som tumregel: köp om det är ett standardiserat problem (ekonomi, HR, grundläggande CRM), bygg om det är er konkurrensfördel, och hyr som SaaS om det är en stödfunktion som inte kräver djup anpassning. Men tumregeln är en utgångspunkt, inte ett facit – varje organisation har undantag som gör den generella regeln fel för just dem.

Den dolda kostnaden av att bygga själv

Byggkalkyler underskattar nästan alltid den löpande kostnaden. En första version byggd av två utvecklare på sex månader kostar sällan under 600 000–900 000 kronor i fullt belastad arbetstid – innan den ens är i produktion. Men den siffran är bara starten. Förvaltning, säkerhetsuppdateringar, buggfixar och vidareutveckling brukar landa på 15–25 procent av byggkostnaden per år, varje år, så länge lösningen lever. Över fem år har den ”billiga” interna lösningen ofta kostat dubbelt så mycket som den SaaS-licens ni valde bort.

Det som sällan syns i kalkylen är alternativkostnaden: de timmar era bästa utvecklare lägger på att underhålla ett internt löneverktyg är timmar de inte lägger på produkten era kunder faktiskt betalar för. Vi ser det gång på gång i arkitekturgranskningar – bolag med imponerande produkt men en stödfunktion som sakta äter upp en tredjedel av teamets kapacitet.

Tid till värde och vad väntan faktiskt kostar

Att bygga tar nästan alltid längre än planerat – det är inte pessimism, det är ett mönster som håller i sig oavsett bransch. En första fungerande version tar sällan under tre till sex månader även för ett välskrivet scope, och den versionen saknar ofta hälften av vad en etablerad SaaS-produkt redan har löst: integrationer, edge cases, säkerhetsuppdateringar, uppdaterad dokumentation. Om er verksamhet blöder pengar eller tappar affärer varje månad ni väntar, väger det tungt mot att bygga – oavsett hur mycket billigare det ser ut på pappret.

Omvänt: om tidsramen är lång och kraven kommer förändras flera gånger under resans gång, kan en köpt lösning bli en tvångströja som kostar mer i anpassningsprojekt och integrationslager än vad det hade kostat att bygga rätt från början. Det är därför vi alltid frågar hur stabila kraven faktiskt är innan vi rekommenderar ett håll.

En enkel poängmodell ni kan använda i eftermiddag

Sätt en poäng 1–5 på varje faktor för det aktuella beslutet: strategiskt värde, tid till värde (hur akut är behovet), total ägandekostnad över fem år (lägre kostnad ger högre poäng för köp) och flexibilitet (hur unika era krav faktiskt är). Vikta strategiskt värde dubbelt – det är den faktor som slår igenom hårdast i praktiken. Om den viktade summan lutar mot att lösningen är strategiskt central, tidskritisk och unik: bygg. Om den lutar mot standardiserad, inte tidskritisk och dyr att underhålla själv: köp. Ligger utfallet nära mitten är det ett tecken på att ni behöver en oberoende second opinion snarare än att gissa – det är precis de fallen som kostar mest att ta fel på.

Vanliga fallgropar vi ser om och om igen

På byggsidan är det klassiska misstaget ”not invented here”: ett tekniskt starkt team som hellre bygger något eget än erkänner att en färdig lösning redan löser 90 procent av behovet bättre än vad de skulle hinna på egen hand. På köpsidan är det motsatta misstaget lika vanligt: överdriven rädsla för inlåsning gör att bolag tackar nej till bra lösningar av principskäl, även när utträdeskostnaden i praktiken är hanterbar. Vi går igenom hur man bedömer den risken nyktert i vår artikel om vendor lock-in.

Det tredje och kanske dyraste misstaget är ”vi kan alltid bygga om det senare” – en sanning med modifikation. Att byta en etablerad, datatung kärnkomponent efter tre år är en helt annan operation än att välja rätt från början, och den kostnaden tas sällan med i det ursprungliga beslutsunderlaget.

Slutsats

Bygga-eller-köpa är sällan en teknisk fråga i grunden – det är en fråga om var er organisations knappa resurs, utvecklarkapacitet, gör mest nytta. En strukturerad modell med fyra viktade faktorer slår magkänsla varje gång, särskilt när beslutet är dyrt att ta fel på. Om ni står inför ett vägval som känns för stort för att avgöra internt, eller vill ha en oberoende genomgång innan ni binder upp er: läs mer om våra tjänster eller boka ett samtal.