Written by:
Last Published:
11 augusti 2026
•
Kortfattat:
De flesta digitala produkter behöver inte ett supportteam på heltid efter lansering. De behöver ett litet, dedikerat team på löpande räkning som övervakar systemet under kontorstid, åtgärdar fel och levererar planerade förbättringar i schemalagda block. Räkna med en årlig budget på 10–20 % av utvecklingskostnaden för att hålla produkten igång, och budgetera separat för det arbete som får den att växa. Den här guiden går igenom vad underhållet omfattar, vad det kostar och hur du upphandlar det.
En digital produkt är mjukvara som dina kunder använder eller köper direkt: en webbapplikation, en mobilapp, en plattform, ett API, en prenumerationstjänst eller en nedladdningsbar tillgång som en mall, en kurs eller en rapport. Ingenting fysiskt byter ägare. Men under ytan finns servrar, beroenden, webbläsare, appbutiker, betalningsleverantörer och säkerhetsuppdateringar, och alla dessa förändras oavsett om någon rör din kod eller inte.
Det är den skillnaden som överraskar många produktägare. En fysisk produkt är färdig när den levereras. En digital produkt liknar mer en båt i vattnet: skrovet behöver skrapas regelbundet, en läcka måste tätas så fort den uppstår, och ett större segel är ett projekt i sig. Lanseringsdagen är när den sjösätts, inte när arbetet upphör. Om du säljer digitala produkter, eller driver en som motorn i en tjänsteverksamhet, är det dagen då driftskostnaderna börjar.
När en digital produkt går live oroar sig produktägare ofta för hur den ska underhållas. Det är en vanlig och befogad oro. Detta är den punkt i livscykeln där produkten behöver mest stöd, och det är också punkten där teknik- och designteamet fasas ut, eftersom det inte är ekonomiskt hållbart att behålla hela teamet.
Det skapar problem för båda parter. Produktägaren förlorar teamet som besitter kunskapen, så ingen som känner till systemet finns tillgänglig när något brådskande inträffar. Byrån får ta emot regelbundna, oplanerade supportförfrågningar som dyker upp medan samma personer arbetar med andra projekt. Kontextbyten under tidspress leder till att deadlines för det nya arbetet halkar efter, och två produkter blir lidande istället för en.
Vad du vill ha istället är ett balanserat upplägg: produktägare får tillgång till ett team vid behov, och projektteam blir inte ständigt avbrutna efter att ett projekt avslutats. För att utforma det behöver du veta vad som faktiskt måste hända när en produkt väl har levererats.
När en produkt väl är lanserad och befinner sig i den så kallade underhållsfasen krävs ett antal olika insatser. Det är avgörande att förstå karaktären på dessa uppgifter, eftersom varje typ köps in, schemaläggs och prissätts på olika sätt. De organiseras vanligtvis enligt följande:
Denna uppdelning är inget vi har hittat på. ISO/IEC/IEEE 14764:2022, den internationella standarden för programvaruunderhåll, formaliserar arbete efter leverans i fyra kategorier: avhjälpande, anpassande, perfektivt och förebyggande. Vår modell med tre linjer motsvarar detta direkt. Förebyggande förblir förebyggande, avhjälpande förblir avhjälpande, och vi grupperar de två förbättringstyperna, anpassande och perfektivt, i en enda linje som vi kallar utvecklande, eftersom de kommersiellt sett köps in och schemaläggs på samma sätt.
Forskningen bakom standarden är enig om en punkt som förvånar de flesta produktägare: majoriteten av underhållsarbetet läggs på förbättringar, inte på att åtgärda fel. I den klassiska studien av Lientz, Swanson och Tompkinsstod perfektivt arbete, det vill säga förbättringar, ensamt för cirka 60 % av underhållsinsatsen, medan avhjälpande felrättning utgjorde under en femtedel. Resultatet har upprepats gång på gång sedan dess.
På Imaginary Cloud hanterar vi dessa tre typer som tre separata linjer i vad vi kallar ett retainer-avtal med tre linjer: en kontrakterad linje vardera för förebyggande, avhjälpande och utvecklande arbete, prissatta och schemalagda oberoende av varandra istället för att tas från en gemensam pott med timmar.
Varför dela upp dem? Därför att de tre fungerar olika. Förebyggande arbete är förutsägbart och kan schemaläggas. Avhjälpande arbete är oförutsägbart och kräver ett åtagande om svarstid. Utvecklande arbete planeras som vilket annat projekt som helst. Enligt vår erfarenhet är en odifferentierad pott med timmar den vanligaste orsaken till att en underhållsbudget tar slut tidigt på året: en incident under första kvartalet äter upp de timmar som var tänkta att täcka tolv månaders uppdateringar, och de planerade förbättringarna är det första som får stryka på foten.
I alla situationer som omfattas av förebyggande och avhjälpande underhåll behöver produktägaren ett team som hanterar befintliga problem. Men de flesta digitala produkter behöver inte ett team som arbetar dygnet runt. Det som behövs är ett team som håller ett öga på systemet och ingriper när det uppstår fel. Med rätt åtgärder på plats är modern infrastruktur tillräckligt stabil för att support under kontorstid ska räcka för de flesta produkter.
Tiden som ägnas åt underhåll avtalas vanligtvis via ett löpande avtal: en fast månadsavgift som reserverar en överenskommen mängd tid hos ett specifikt team, oavsett om du använder all tid den månaden eller inte. Du betalar lika mycket för tillgänglighet och bibehållen kontext som för faktiska arbetstimmar. För att göra detta effektivt håller teamet uppsikt över flera produkter samtidigt och kör standardiserade processer för tjänster som serverövervakning och säkerhetsuppdateringar.
I vissa fall behöver du support dygnet runt, och det är en helt annan typ av tjänst. Räkna med att betala ett högre pris, vanligtvis till ett företag som är specialiserat på underhållsavtal, eftersom det kräver schemalagd personal och eskaleringsrutiner som bara fungerar i mycket större skala.
Det är i det avhjälpande underhållet som svarstider fastställs, och luddiga formuleringar här är vad som orsakar konflikter senare. Ett fungerande servicenivåavtal (SLA) anger tre saker för varje allvarlighetsgrad: hur snabbt någon bekräftar rapporten, hur snabbt arbetet påbörjas och vad målet är för en lösning eller en tillfällig åtgärd. En vanlig struktur för ett avtal under kontorstid ser ut så här:
| Allvarlighetsgrad | Exempel | Bekräftelse | Mållösning |
|---|---|---|---|
| Kritisk | Produkten ligger nere, kassan fungerar inte, data är i fara | Inom 1 arbetstimme | Samma arbetsdag, tillfällig lösning först |
| Hög | Kärnfunktion ur funktion för många användare | Inom 4 arbetstimmar | Nästa arbetsdag |
| Medium | Icke-kritiskt fel, tillfällig lösning finns | Inom 1 arbetsdag | Nästa planerade releaserelease |
| Låg | Kosmetiskt problem, mindre innehållsändring | Inom 2 arbetsdagar | Buntas ihop i planerat arbete |
Kom överens om definitionerna för varje allvarlighetsgrad innan ni skriver på, inte under er första incident. Bestäm vem som har rätt att deklarera ett kritiskt problem. Och kom överens om vad som händer med månadens planerade arbete när ett sådant problem uppstår.
Support under kontorstid fungerar bara om systemet meddelar dig att det är problem, istället för att du väntar på att en kund ska göra det. En fungerande baslinje för övervakning omfattar drifttid och kontroll av slutpunkter, felspårning med aviseringar, loggsamling, infrastrukturmått som CPU, minne och disk, databasprestanda och långsamma frågor, verifiering av säkerhetskopior med testad återställning, samt beroende- och sårbarhetsskanning mot offentliga råd som National Vulnerability Database och vägledningen publicerad av OWASP.
Det sistnämnda är vad som förvandlar förebyggande underhåll från en kalenderövning till ett verkligt skydd. När en sårbarhet upptäcks i ett ramverk du är beroende av, är frågan inte om du kommer att åtgärda den. Frågan är hur många dagar som går innan du vet att den existerar.
Evolutivt underhåll handlar främst om affärstillväxt och förbättring av tjänster, och det kan planeras och genomföras i god tid. Sammanställ en lista med uppgifter och be sedan din teknikpartner att sätta ihop ett team för att hantera dem under ett par sprintar: fasta block av utvecklingsarbete, vanligtvis en eller två veckor långa, med ett överenskommet omfång vid start och en release vid avslut.
Att hålla evolutivt arbete i en egen ström, i schemalagda sprintar istället för att låta det sippra in via supportkanalen, skyddar båda parter. Produktägaren får en förutsägbar releasecykel och en tydlig kostnad per block. Teamet kan planera sin kapacitet, vilket är ett annat sätt att säga att ingen behöver ryckas från ett annat projekt med en halv dags varsel. Se Waterfall vs Agile: när du bör använda respektive metod för hur de två planeringsstilarna står sig mot varandra när du strukturerar dessa block.
Det är också här tillväxtarbetet sker. Att bygga om en produkt så att den kan hantera fler användare är ett klassiskt evolutivt projekt: vi byggde om GoodBarbers upplevelse för app-byggande på en mer skalbar arkitektur på precis detta sätt, vilket du kan läsa mer om i GoodBarber Composer-casestudien.
Den enskilt största drivkraften bakom evolutiva kostnader är inte funktionens storlek. Det är hur svår den befintliga kodbasen är att ändra. Den svårigheten har ett namn, teknisk skuld, och om den lämnas ohanterad ökar den i tysthet kostnaden för varje förbättring du levererar. Robert Glass påpekade samma sak för decennier sedan: den dominerande uppgiften vid underhåll är att förstå den befintliga produkten innan man säkert kan röra den.
Sättet att hålla den kostnaden synlig är att mäta den. En periodisk kodgranskning som poängsätter underhållbarhet, komplexitet och testtäckning visar var skulden ligger innan den spårar ur en release. Vi tog fram pseudokoddokumentation för 195 mallar åt GoodBarber, vilket beskrivs i casestudien om kodstandardisering, så att de kunde fatta arkitektoniska beslut baserade på fakta snarare än gissningar inför en större ombyggnad. För en bredare bild beskriver vår guide om hur man hanterar teknisk skuld de praktiska alternativen.
Digitala produkter är inte en enhetlig kategori ur ett kommersiellt perspektiv. Hur din produkt genererar intäkter avgör vad driftstopp kostar dig, hur snabbt du måste åtgärda fel och vilken av de tre underhållskategorierna som väger tyngst. Fem huvudtyper täcker större delen av marknaden.
Det praktiska syftet med denna lista är att hjälpa dig dimensionera dina behov. Räkna först ut vad en timmes driftstopp kostar i din modell, och köp sedan det supportavtal som matchar den kostnaden. En marknadsplats med hög transaktionsvolym och en mallbutik med femtio försäljningar i månaden är båda digitala produkter, men de bör inte köpa samma typ av support.
Instinkten efter en lansering är att dimensionera teamet efter den sämsta månaden. Det är det som gör att underhåll ser oöverkomligt dyrt ut, och det är en felaktig kalkyl, eftersom den sämsta månaden inte är den genomsnittliga månaden.
För de flesta produkter under deras första år är en effektiv lösning ett delat team snarare än ett dedikerat: en deltidsingenjör som har koll på produktens kontext, en deltids-DevOps eller plattformsingenjör som sköter infrastruktur och övervakning, samt tillgång till en designer och en ledare för större utvecklingssteg. Det är en bråkdel av kostnaden för en heltidsresurs, och det är bättre än en dedikerad junior när det gäller tillgänglighet, eftersom det täcker semestrar, sjukdom och den specialistkompetens som en enskild person inte besitter. När en produkt väl har ett eget team fungerar även en integrerad modell bra: vi anslöt oss till AppTweaks team som en integrerad frontend-enhet och följde deras egna processer. Tre avtalsmodeller täcker nästan alla situationer:
| Modell | Vad du får | Bäst för |
|---|---|---|
| Abonnemang under arbetstid | Fast månadsavgift, överenskommet antal timmar, responstid under arbetstid. Ej nyttjade timmar takbegränsas vanligtvis och sparas inte. | De flesta produkter; modellen som abonnemang i tre nivåer är byggd för |
| Löpande räkning (Tid och material) | Betala för det du använder, ingen tillgänglighetsgaranti. Billigast på papperet, dyrast vid en incident eftersom du hamnar i kön. | Interna verktyg, låg kommersiell exponering |
| 24/7 eller utökad täckning | Schema-bemanning, jour-eskalering, högre prissättning. | Transaktionsplattformar, reglerade eller säkerhetskritiska tjänster |
Avgör vilken modell du ska välja genom att fråga dig vad en timmes driftstopp kostar dig, inte vad månadsavgiften kostar. Företag som säljer digitala produkter kontinuerligt, snarare än i projektcykler, upptäcker nästan alltid att månadsavgiften är det billigare alternativet.
För de produkter vi levererar och därefter stöttar, ligger kostnaden för förebyggande och korrigerande underhåll på 10–20 % av den ursprungliga utvecklingskostnaden per år, vilket är det intervall vi budgeterar med våra kunder. Detta stämmer väl överens med bredare forskning om livscykelkostnader för mjukvara: Robert Glass anger underhåll till 40–80 % av den totala livscykelkostnaden, med ett genomsnitt på 60 %, i Facts and Fallacies of Software Engineering (2002), vilket under en produkts livstid är mer än den ursprungliga utvecklingskostnaden.
I praktiken innebär det att en produkt som kostade 150 000 pund att utveckla bör ha en årlig driftsbudget på cirka 15 000 till 30 000 pund, exklusive nya funktioner. Var du hamnar i det intervallet beror på den valda affärsmodellen, antalet tredjepartsintegrationer och hur stor del av tekniken du själv kontrollerar.
Evolutivt underhåll ingår inte i den siffran, eftersom det är kopplat till hur mycket produkten förväntas växa. Betrakta det som en separat budgetpost, den tredje raden i löpande avtal, och basera den på din färdplan snarare än på utvecklingskostnaden. En produkt i en aktiv tillväxtfas kan enkelt lägga mer på evolutivt arbete under ett år än vad de förebyggande och korrigerande posterna kostar tillsammans.
Två kostnader utelämnas rutinmässigt från den första budgeten men dyker upp ändå: tredjepartstjänster (hosting, övervakning, felspårning och betal-API:er) samt kostnader för appbutiker och efterlevnad för att hålla en mobil produkt publicerbar i takt med att plattformarnas krav förändras.
Arbeta med svaren från dag ett tillsammans med din mjukvarupartner. Var öppen med dina farhågor och fastställ i avtalet vad som händer om något går fel, istället för att utgå från att god vilja löser allt. Det förhindrar att du efter lanseringen hamnar i en situation där ett problem inte kan lösas utan konflikt – och när det väl händer är det dina användare, och i förlängningen din verksamhet, som drabbas först.
Något som kunder använder eller köper utan att något fysiskt byter ägare: en webb- eller mobilapplikation, en plattform, ett API, en prenumerationstjänst eller en nedladdningsbar tillgång som en mall, kurs eller rapport. Alla dessa är beroende av infrastruktur, tredjepartstjänster och kodbibliotek som ständigt förändras, vilket är anledningen till att varje digital produkt medför löpande kostnader efter lansering.
Budgetera 10–20 % av den ursprungliga byggkostnaden per år för förebyggande och korrigerande underhåll. En produkt som kostade 150 000 pund att bygga hamnar på ungefär 15 000 till 30 000 pund per år. Evolutivt underhåll, det vill säga nya funktioner och tillväxtarbete, budgeteras separat utifrån din roadmap.
De flesta gör inte det. Med övervakning, larm och ett avtal för support under kontorstid är de flesta produkter tillräckligt skyddade. Support dygnet runt är motiverat när en timmes driftstopp innebär direkta intäktsförluster, regulatoriska problem eller säkerhetsrisker, och köps vanligtvis från ett företag som är specialiserat på underhållsavtal.
Arbete som förbättrar eller utökar en live-produkt snarare än att bara hålla den igång: nya funktioner, prestandaoptimeringar, utökad kapacitet och integrationer. Det motsvarar vad ISO 14764 kallar adaptivt och perfektivt underhåll, släpps i sprintar precis som annat utvecklingsarbete, och bör avtalas och budgeteras separat från support.
Förebyggande underhåll är schemalagt arbete som förhindrar att fel uppstår, till exempel att installera säkerhetsuppdateringar och förnya certifikat. Korrigerande underhåll är det reaktiva arbetet efter att något redan har gått sönder, till exempel att återställa en server som slutat fungera. Förebyggande arbete är förutsägbart och planerbart; korrigerande arbete kräver ett åtagande om svarstid.
Ett namngivet team, ett överenskommet månatligt timpaket, mål för svarstid och problemlösning baserat på allvarlighetsgrad, en definierad uppsättning för övervakning och larm, en rutin för uppdateringar samt en fastställd process för vad som händer med planerat arbete när en kritisk incident inträffar, inklusive vem som har befogenhet att deklarera en sådan.
Mindre tekniskt arbete än för en SaaS-produkt, men den kommersiella ytan måste fortfarande underhållas: kassa, integrationer med betalningsleverantörer, licenshantering, filhosting och åtkomstkontroll. Den största risken ligger i det förebyggande arbetet, eftersom de delar som är mest benägna att gå sönder är tredjepartstjänster som ändras enligt sitt eget schema.
Det kan ni, och det är rimligt när produkten är tillräckligt stor för att hålla ett heltids-team genuint sysselsatt. Under den nivån täcker ett externt team via ett underhållsavtal semestrar, sjukdom och specialistkompetens som en enskild intern anställd inte kan erbjuda, oftast till en lägre kostnad än en heltidslön.
Om din produkt närmar sig lansering, eller redan är live och supportas informellt, är det värt att formalisera upplägget innan den första incidenten tvingar fram det. Vårt team kan granska er nuvarande uppsättning och föreslå en form av underhållsavtal som matchar produktens faktiska risk snarare än ett värsta scenario.
Kontakta oss angående support efter lansering så går vi igenom vad din produkt behöver och vad det bör kosta. Du kan boka ett samtal här.
VD på Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i den ordningen).
LinkedIn
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
People who read this post, also found these interesting:
