Vad är den totala ägandekostnaden för en digital produkt?
Den totala ägandekostnaden för en digital produkt omfattar allt från utveckling till avveckling. Själva utvecklingen står typiskt för 40–60 procent av treårskostnaden – resten är drift, förvaltning, vidareutveckling, licenser och support. En produkt som är billigast att bygga kan därför bli dyrast att äga, om kvaliteten skapar merkostnader efter lansering.
Offerten visar vad produkten kostar att bygga. Vad den kostar att äga är en annan – och större – siffra, som få leverantörer visar självmant. Räknar du på tre år i stället för på leveransdagen fattar du bättre beslut i nästan varje vägval.
Utvecklingen är bara 40–60 procent av kostnaden
Över en treårsperiod står själva utvecklingen typiskt för 40–60 procent av den totala ägandekostnaden. Resten fördelas på drift, förvaltning, vidareutveckling, licenser, support och er egen interna tid. Det betyder att den siffra de flesta förhandlar hårdast om – byggpriset – är ungefär halva sanningen.
Kalkylmall: posterna som ska med
| Kostnadspost | Typisk nivå |
|---|---|
| Utveckling (engångskostnad) | 40–60 % av treårskostnaden |
| Drift och hosting | Varierar med last och tillgänglighetskrav; från några tusenlappar per månad |
| Förvaltning (felrättning, uppdateringar, support) | 15–25 % av byggkostnaden per år |
| Vidareutveckling (nya funktioner) | 20–40 % av byggkostnaden per år, efter ambition |
| Licenser och tredjepartstjänster | Betalningar, kartor, e-post, analys – växer ofta med användningen |
| Support och intern tid | Ofta bortglömd: er egen administration, beställar- och testtid |
Gå igenom raderna med varje leverantör ni utvärderar och be om uppskattningar per post. Den som inte kan resonera kring åren efter lansering har inte tänkt hela vägen.
Räkneexempel: billigast att bygga, dyrast att äga
Två offerter på samma produkt: A på 700 000 kr och B på 1 000 000 kr. B:s högre pris köper testautomatisering, dokumentation och en mer genomarbetad arkitektur. Siffrorna nedan är illustrativa, men mekanismen är verklig.
Produkt A kräver tät felrättning – förvaltning i övre spannet, 25 procent, alltså 175 000 kr per år. Vidareutvecklingen går trögt i den snåriga kodbasen: 300 000 kr per år för måttlig utvecklingstakt. Efter tre år: 700 000 + 525 000 + 900 000 = cirka 2,1 miljoner kr.
Produkt B förvaltas för 15 procent, 150 000 kr per år, och samma utvecklingstakt kostar 200 000 kr per år. Efter tre år: 1 000 000 + 450 000 + 600 000 = cirka 2,05 miljoner kr.
Det “dyrare” bygget är redan efter tre år totalt billigare – och gapet växer för varje år produkten lever, eftersom skillnaden ligger i de återkommande posterna. Lägg till drift och licenser, som är ungefär lika stora i båda fallen, och slutsatsen står sig.
Därför blir billiga byggen dyra
- Genvägar i arkitekturen gör varje ny funktion dyrare att lägga till.
- Saknade tester gör varje ändring riskabel – och försiktighet kostar timmar.
- Tunn dokumentation låser er till leverantören som byggde, med prissättningen det medför.
- Snål testning före lansering flyttar felen till produktion, där de är som dyrast att hitta och åtgärda.
Inget av detta syns i offerten. Allt syns i TCO.
Glöm inte er egen tid
Den mest underskattade posten i kalkylen är intern tid: någon hos er ska prioritera backloggen, svara på leverantörens frågor, testa leveranser och ta hand om användarnas återkoppling. För en aktiv produkt handlar det ofta om en betydande del av en tjänst. Den tiden syns aldrig på en faktura – men den är en kostnad, och utan den levererar även den bästa leverantören fel saker.
Räkna till sist med en post som nästan aldrig budgeteras: avveckling eller ersättning. Data ska exporteras, integrationer kopplas ur och användare flyttas den dag produkten byts ut. Det behöver inte kosta mycket – om exportvägar och ägarskap fanns med i kraven från början.
Så använder du TCO när du köper utveckling
- Be varje leverantör om en treårskalkyl, inte bara ett byggpris.
- Jämför offerter på totalkostnad inklusive förvaltning och drift.
- Budgetera för år två redan vid beställningen – produkten är inte klar för att den är lanserad.
- Fråga vad som görs i bygget för att hålla ägandekostnaden nere: tester, standardteknik, dokumentation.
Vi på Weapp redovisar gärna hela treårsbilden i våra offerter – det är den kalkyl vi själva skulle kräva som beställare. Vill du se hur den ser ut för er produkt? Hör av dig eller läs mer om våra tjänster.
Vanliga frågor
Hur många år ska en TCO-kalkyl omfatta?
Tre år är en vanlig och hanterbar horisont för digitala produkter – tillräckligt lång för att driftskostnaderna ska synas, tillräckligt kort för att gå att uppskatta seriöst. För kärnsystem med lång livslängd räknar många på fem år i stället.
Hur sänker jag ägandekostnaden utan att sänka kvaliteten?
Välj standardteknik som många utvecklare behärskar, använd molntjänster i stället för egen drift, kräv automatiserade tester och löpande dokumentation och undvik leverantörsinlåsning. Allt detta sänker kostnaden för åren efter lansering – där merparten av pengarna finns.
Är hög förvaltningskostnad alltid ett dåligt tecken?
Nej. En produkt med många användare och hög förändringstakt kostar naturligt mer att hålla i toppskick, och det kan vara utmärkt använda pengar. Varningssignalen är hög förvaltningskostnad utan motsvarande värde – när pengarna går till att hålla något flytande snarare än att göra det bättre.
Vad kostar driften av en app eller webbtjänst per månad?
Det varierar med last och tillgänglighetskrav: enklare produkter klarar sig ofta på några tusenlappar i månaden i molnkostnader, medan affärskritiska tjänster med redundans, hög trafik och skarpa krav kostar betydligt mer. Be leverantören om en uppskattning per miljö redan i offerten.
Hur påverkas TCO om produkten byggs med no-code?
Startkostnaden sjunker men plattformsavgifterna, som ofta skalar per användare, ersätter delar av utvecklings- och driftkostnaden. Lägg dessutom in en exitkostnad i kalkylen: logiken bor i plattformen och måste byggas om den dag ni växer ur den.