Så uppskattar du kostnaden för programvaruutveckling på rätt sätt

Många svenska företag underskattar kostnaden för digitala projekt långt innan utvecklarna skriver den första raden kod. Problemet börjar sällan i själva programmeringen. Det börjar i hur behovet definieras, vilka antaganden som görs och vilka kostnader som lämnas utanför den första kalkylen.

Det är vanligt att ett företag tänker på programvaran som ett avgränsat projekt: en kravlista ska förvandlas till en leverans inom en bestämd tid och budget. Men en fungerande digital lösning är också en produkt som måste drivas, säkras, stödjas och förbättras efter lanseringen.

När budgeten bara täcker vägen fram till lanseringen blir den därför missvisande redan från början.

Otydliga behov skapar dyra uppskattningar

En tillförlitlig kalkyl kräver att företaget först förstår varför lösningen behövs. Vilket affärsproblem ska den lösa? Vilka människor ska använda den? Vilket resultat ska förändras?

Om dessa frågor saknar tydliga svar kan leverantören bara uppskatta utifrån antaganden. Företaget kan ha en detaljerad funktionslista men ändå sakna en gemensam bild av affärsnyttan. Då upptäcks viktiga krav, dataflöden och integrationer ofta sent.

Resultatet blir ändringar under utvecklingen, så kallad scope creep. Varje enskilt tillägg kan verka litet, men tillsammans påverkar de design, arkitektur, testning, tidsplan och kostnad.

Ett annat vanligt misstag är att räkna på utvecklarnas arbete men glömma resten. Enligt forskningsunderlaget kan design, projektledning, test, drift, support och underhåll motsvara ytterligare 30–50 procent av utvecklingskostnaden.

En senior utvecklare kostar typiskt omkring 950–1 400 kronor per timme, medan juniora profiler ofta ligger på 650–900 kronor per timme. Specialister inom AI och maskininlärning kan kosta ännu mer.

Det billigaste timpriset ger därför inte automatiskt den lägsta totalkostnaden. En oerfaren resurs kan behöva fler timmar, skapa mer omarbete eller välja tekniska lösningar som blir dyra att förvalta.

Den svenska verkligheten gör budgetfrågan viktigare

Svenska företag verkar i en digital men kostsam ekonomi. Den genomsnittliga totala arbetskraftskostnaden för en tjänsteman i privat sektor låg enligt underlaget på cirka 81 755 kronor per månad i april 2025.

Om fyra medarbetare förlorar tio procent av sin arbetstid på manuella kontroller, dubbelregistrering och brister i systemen motsvarar det nästan 400 000 kronor per år. Den kostnaden syns sällan som en egen post, men den påverkar lönsamheten varje månad.

Samtidigt köpte 72 procent av svenska företag med minst tio anställda molntjänster under 2025, och 35 procent använde AI. Molntjänster gör det möjligt att bygga skalbara lösningar, men de innebär också löpande kostnader för databaser, lagring, trafik, licenser, övervakning och säkerhet.

Tillväxtverket visar dessutom att 74 procent av svenska företag vill växa och att 62 procent av de tillväxtambitiösa företagen möter minst ett stort hinder. Kompetensbrist är en viktig del av problemet. Bristen på rätt kompetens kan försena utvecklingen, driva upp konsultkostnader och öka risken för felaktiga teknikval.

Vad kostar programvaruutveckling i Sverige?

Det finns inget enda korrekt pris för en digital lösning. Kostnaden beror på funktionalitet, användarantal, säkerhetskrav, integrationer, design, datamängder och teknisk komplexitet.

I forskningsunderlaget anges följande ungefärliga svenska branschintervall:

  • En enkel webbplats eller portal: cirka 20 000–80 000 kronor.
  • En mobilapp eller MVP: cirka 100 000–300 000 kronor på enkel nivå och 300 000–600 000 kronor på medelnivå.
  • En medelstor webbapplikation eller SaaS-lösning: cirka 500 000–1 200 000 kronor.
  • Ett komplext system eller specialanpassat CRM: omkring 1,2–3 miljoner kronor eller mer.
  • En enskild systemintegration: ofta 50 000–150 000 kronor, beroende på systemen och datakvaliteten.

Intervallen är vägledning, inte offerter. Två lösningar som ser likadana ut på ytan kan få helt olika kostnader beroende på exempelvis behörighetsnivåer, offline-stöd, historiska data, externa API:er eller krav på hög tillgänglighet.

Programmeringen är bara en del av budgeten

I en realistisk budget kan själva utvecklingen stå för ungefär 40–50 procent av helheten. Resten består av arbete och kostnader som är nödvändiga för att lösningen ska fungera i praktiken.

Produkt- och projektledning kan motsvara 10–15 procent. Här ingår kravarbete, prioritering, avstämningar, riskhantering och beslut om förändringar.

Design och användarupplevelse kan motsvara 10–20 procent. Det omfattar användarflöden, prototyper, visuellt gränssnitt och tester med riktiga användare.

Test och kvalitetssäkring bör ofta få minst 10–15 procent. Systemet behöver testas i olika webbläsare och enheter samt granskas för prestanda, säkerhet och felhantering.

Därtill kommer moln- och driftmiljö. För en mindre applikation kan den löpande kostnaden ligga omkring 1 000–5 000 kronor per månad, men större system kan bli betydligt dyrare. Informationen måste också skyddas under överföring och lagring.

Support, övervakning och underhåll kan för ett mindre system motsvara cirka 10 000–20 000 kronor per månad. Utbildning och dokumentation kan kräva ytterligare 5–10 procent av budgeten.

Ett system kan därför under fem år kosta lika mycket i drift och förvaltning som i den ursprungliga utvecklingen. En budget som bara visar byggkostnaden beskriver inte den verkliga investeringen.

En bättre metod för kostnadsuppskattning

Börja med affärsbehovet, inte med en lång funktionslista. Beskriv målet, användarna och det problem som ska lösas. Definiera därefter en första version, en MVP, som innehåller det minsta som krävs för att skapa och testa värde.

Bryt sedan ned lösningen i användarberättelser eller tydliga funktioner. Varje del bör uppskattas separat, inklusive design, utveckling, testning och införande.

Genomför också en teknisk inventering. Vilka befintliga system ska kopplas ihop? Hur ser datakvaliteten ut? Vilka licenser och externa tjänster behövs? Finns det krav på GDPR, loggning, kryptering eller särskilda behörigheter?

Välj därefter en lämplig kommersiell modell. Fast pris kan fungera när omfattningen är mycket tydlig. Vid hög osäkerhet är tid och material ofta mer realistiskt, eftersom företaget kan prioritera och justera lösningen när ny kunskap uppstår.

Lägg slutligen till en buffert på 10–30 procent beroende på osäkerheten och projektets längd. Testa även olika scenarier:

Vad händer om arbetet tar 20 procent längre tid? Vad händer om en integration blir mer komplicerad eller om externa kostnader stiger?

Följ budgeten medan det fortfarande går att agera

En budget ska inte läggas i en mapp efter projektstarten. Den behöver följas upp kontinuerligt.

Jämför planerad kostnad med faktiskt utfall. En avvikelse inom ungefär tio procent kan vara hanterbar, medan större skillnader kräver en ny prognos.

Följ också hur stor del av lösningen som är färdig jämfört med hur stor del av budgeten som är förbrukad. Om 60 procent av pengarna är använda men bara 35 procent av det prioriterade arbetet är klart finns ett problem som måste hanteras direkt.

Mät dessutom förändringsfrekvensen. Många sena ändringar tyder ofta på att behovet inte var tillräckligt utforskat före utvecklingen.

Vid extern upphandling bör betalningar kopplas till tydliga milstolpar och levererade resultat, inte bara till kalenderdatum. Krav bör beskriva både funktionalitet och affärsnytta, och avtalet behöver innehålla en tydlig modell för ändringar.

Den rätta budgeten börjar med ärlighet

En realistisk programvarubudget bygger inte på det lägsta tänkbara priset. Den bygger på en ärlig bild av osäkerhet, kompetensbehov, drift och långsiktigt ansvar.

Planera tidigt, använd erfarenheter från jämförbara projekt och inkludera hela livscykeln. Följ upp prognosen regelbundet och koppla investeringen till mätbar affärsnytta.

De flesta budgetproblem börjar innan utvecklarna kommer in i rummet. Det positiva är att samma sak gäller lösningen: med bättre frågor, bättre förberedelser och en fullständig kostnadsbild kan många av problemen undvikas innan den första raden kod skrivs.