Vad kostar det att vidareutveckla en digital produkt?
Vidareutveckling efter lansering kostar typiskt 20–40 procent av den ursprungliga byggkostnaden per år. En produkt byggd för 1,5 miljoner kronor behöver alltså en årsbudget på ungefär 300 000–600 000 kronor för ny funktionalitet. Budgeten kan organiseras som ett kontinuerligt team eller som beställningsdriven utveckling – valet styrs av förändringstakten.
Efter lansering delar produktens ekonomi upp sig i tre budgetar: drift (att den snurrar), förvaltning (att den fortsätter fungera) och vidareutveckling (att den blir bättre). Den här sidan handlar om den tredje – den som avgör om produkten är mer värd nästa år än i år.
Tumregeln: 20–40 procent av byggkostnaden per år
En användbar planeringsregel är att aktiv vidareutveckling kostar 20–40 procent av den ursprungliga byggkostnaden per år. En produkt byggd för 1,5 miljoner kr behöver alltså 300 000–600 000 kr om året för att utvecklas i rimlig takt.
Var i spannet ni bör ligga styrs av tre saker:
- Konkurrenstryck. En kundvänd produkt på en rörlig marknad kräver mer; ett stabilt internt verktyg mindre.
- Fas. Första året efter lansering ligger de flesta högt – där samlas allt som prioriterades bort plus lärdomarna från verklig användning.
- Ambition. Ska produkten bara hänga med, eller är den ett konkurrensmedel som ska dra ifrån?
Vad räknas som vidareutveckling?
Nya funktioner, förbättrade flöden, nya integrationer, stöd för fler plattformar och större designarbeten – allt som gör produkten mer värd än när den lanserades. Håll isär det från förvaltningen, som håller produkten i fungerande skick och typiskt kostar 15–25 procent av byggkostnaden per år, och från driften som betalar servrar och licenser.
Tre budgetar, tre olika beslut: driften är obligatorisk, förvaltningen nödvändig och vidareutvecklingen en investering som ska motiveras av sin effekt. Blandas de ihop äter det akuta alltid upp det viktiga.
Två sätt att organisera budgeten
| Modell | Så fungerar den | Passar när |
|---|---|---|
| Kontinuerligt team | Fast utvecklingskapacitet varje månad som arbetar mot en prioriterad backlog | Hög förändringstakt och produkt som är central för affären |
| Beställningsdriven | Behov samlas ihop och beställs som paket med offert per initiativ | Låg eller ojämn förändringstakt med tydligt avgränsade behov |
Det kontinuerliga teamet ger fart och ackumulerad produktkunskap – ingen startsträcka när något ska byggas – men kräver att ni matar det med prioriterat innehåll varje månad. Den beställningsdrivna modellen ger kontroll per krona, men varje initiativ betalar en inläsningskostnad, och kunskapen om er produkt tappas mellan varven.
En vanlig medelväg: en mindre fast kapacitet som håller tempot uppe, kompletterad med separat offererade större initiativ. Vilken modell ni än väljer – skriv in i avtalet hur snabbt kapaciteten kan skalas upp och ner, så att budgeten följer verksamheten och inte tvärtom.
Prioriteringen som får budgeten att räcka
Vidareutvecklingsbudgetar slösas sällan bort på dyra timmar – de slösas på fel saker. En enkel process räcker långt:
- Samla alla önskemål på ett ställe, från användare, support, säljare och ledning.
- Skatta effekt och insats grovt – hög, mellan, låg räcker. Kräv att effekten kopplas till något mätbart.
- Bygg hög effekt och låg insats först. Det låter självklart och görs förvånansvärt sällan.
- Ompröva kvartalsvis i stället för att låsa en årsplan – verkligheten hinner ändra sig.
- Mät efteråt. Blev effekten verklig? Svaret vässar nästa kvartals beslut.
Och våga säga nej. Varje funktion som byggs ska också förvaltas – ett ja i dag är en löpande kostnad i morgon. Nya önskemål under kvartalet får gärna tas in, men då åker något annat ut; en budget utan den regeln växer tyst tills någon upptäcker det i bokslutet.
Räkneexempel: årsbudget för en bokningsapp
En bokningsapp byggd för 1,2 miljoner kr får året efter lansering en vidareutvecklingsbudget på 30 procent: 360 000 kr, ungefär 30 000 kr i månaden i fast kapacitet. Kvartal ett läggs på det mest efterfrågade från lanseringen: förbättrat betalflöde och påminnelser. Kvartal två byggs integrationen mot kassasystemet som väntade på bevisad efterfrågan. Omdesignen av startsidan – hög insats, oklar effekt – får vänta tills mätningarna motiverar den. Så håller en begränsad budget produkten på offensiven.
Vi på Weapp arbetar helst med just prioriterad, mätdriven vidareutveckling – det är där en produkt tjänar igen sin byggkostnad. Vill du resonera om rätt nivå för er? Hör av dig.
Vanliga frågor
Vad är skillnaden mellan förvaltning och vidareutveckling?
Förvaltning håller produkten i fungerande skick: felrättning, säkerhetsuppdateringar och support. Vidareutveckling tillför nytt värde: funktioner, förbättrade flöden, nya integrationer. De bör budgeteras och avtalas separat, annars äter det akuta alltid upp det viktiga.
Hur stor bör budgeten vara första året efter lansering?
Ofta i den övre delen av spannet 20–40 procent av byggkostnaden. Första året samlas allt som prioriterades bort före lansering, plus lärdomarna från verkliga användare – det är normalt årets mest värdefulla utvecklingsbudget, inte ett misslyckande.
Kan man pausa vidareutvecklingen för att spara pengar?
Ja, till skillnad från förvaltningen är vidareutveckling frivillig. En stabil intern produkt kan vila utan dramatik. För konkurrensutsatta produkter är priset i stället att ni halkar efter i funktionalitet och upplevelse. Pausa som ett medvetet beslut med omprövningsdatum – inte av glömska.
Hur avgör jag om en funktion är värd att bygga?
Skatta förväntad effekt mot uppskattad insats och koppla effekten till något mätbart: fler avslut, färre supportärenden, sparad handläggningstid. Bygg minsta version som kan bevisa värdet innan ni bygger hela visionen. Och kom ihåg att allt som byggs också ska förvaltas.
Vem bör prioritera vad som byggs?
Någon hos er med mandat och närhet till affären – ofta i rollen produktägare. Leverantören kan fasilitera processen och bidra med insatsuppskattningar, men prioriteringen är ett affärsbeslut. Utan tydligt ägarskap styr den som ropar högst.