Når første version er leveret, begynder den del af arbejdet, som mange tilbud ikke dækker. Fire opgaver skal have en ejer dagen efter lanceringen: drift, opdateringer, fejlretning og support. Står der ikke et navn ved hver, falder de mellem to stole, og det opdager I først, når en kunde ringer. Samtidig skal I beslutte, hvad næste version skal lære jer. Her er, hvad der skal være aftalt, og i hvilken rækkefølge I tager det.
Dagen før og dagen efter
Inden I åbner for rigtige kunder, bør fem ting være afprøvet:
- Backup kører, og nogen har prøvet at gendanne fra den.
- Fejl og nedbrud giver besked til en person, der kan reagere.
- Der er en plan for, hvordan en ny version lægges ud, og hvordan den rulles tilbage.
- I ejer domæne, cloudkonto, app-butikskonti og kodearkiv, se jeres ejerskab af kode og konti.
- Kunderne ved, hvor de henvender sig.
Dagen efter lanceringen skal I følge med. Hvad gør brugerne? Hvor går de i stå? Hvilke fejl kommer ind? Lidt enkel måling af brugen fortæller mere end en lang samtale, og den giver grundlag for næste prioritering.
Drift: hvem holder produktet kørende?
Drift dækker det at holde produktet tilgængeligt: servere eller cloudtjenester, overvågning, backup, certifikater og domæne. Spørgsmålet er, hvem der gør det, og hvem der får besked klokken to om natten.
I en lille virksomhed er det ofte udviklerne selv eller leverandøren. Begge dele er fint, når det er aftalt. Er aftalen med leverandøren udløbet med leverancen, står I uden nogen. Kig derfor efter, hvad I har købt: leverance alene eller leverance plus drift. Når produktet vokser, kan I se på hvem der skal eje driften.
Opdateringer: det stille arbejde
Software består af jeres egen kode og mange færdige biblioteker og tjenester, som andre vedligeholder. De får sikkerhedsrettelser, og nogle stopper med at blive understøttet. Mobilapps skal desuden følge med nye styresystemer og butikkernes krav.
Spørg leverandøren:
- Hvem holder øje med sikkerhedsopdateringer?
- Hvor tit opdateres biblioteker og platforme?
- Er det med i aftalen, eller betales det særskilt?
Lever I en app eller et andet program, der installeres hos brugeren, så se på Cyber Resilience Act, EU’s forordning om sikkerhed i produkter med digitale elementer. Pligten til at underrette om aktivt udnyttede sårbarheder gælder allerede. Efter Kommissionens opfattelse i en ikke-bindende vejledning kan en ren webapplikation falde uden for, mens en app ofte er omfattet. Afklar jeres situation i artiklen om webapps og CRA.
Fejlretning: hvad er en fejl?
Første version vil have fejl. Det vigtige er, at I har aftalt, hvad der sker.
- Hvad er en fejl, og hvad er et ændringsønske? Uenighed om det koster mange samtaler. Beskriv det i hvornår en leverance er færdig.
- Hvor hurtigt skal alvorlige fejl rettes? Del fejl op i tre grader, og aftal svartid på hver.
- Hvor længe dækker leverancen? Mange aftaler har en periode efter lancering. Hvad sker bagefter?
- Hvor registreres fejl? Ét sted, hvor I selv kan se dem.
Support: hvem svarer kunden?
I starten bør stifteren selv svare på henvendelser. Det er den hurtigste måde at lære produktet og kunderne at kende. Skriv de spørgsmål ned, der går igen. De er jeres vigtigste kilde til næste version.
Aftal, hvordan en sag går videre til en udvikler, så udviklerne ikke bliver afbrudt af alt. Læg et sted, hvor I kan melde om driftsproblemer til kunderne. Det kan være en enkel side, og det hjælper meget den dag, noget går galt.
Næste version
Første version var bygget for at lære noget. Hvad lærte I? Saml det, I har fra brugerne, fra support og fra tallene for brug, og vælg det næste spørgsmål. Lav en kort liste over tre ting, frem for en plan for hele året. Ud over nye funktioner skal der afsættes tid til at rydde op i de hurtige løsninger fra første version. Hvis I lader dem ligge, bliver det gradvist dyrere at ændre produktet, se teknisk gæld forklaret for ledelsen.
Tre spørgsmål afgør, hvem der skal bygge videre:
- Fortsætter samme leverandør, eller er det tid til noget andet?
- Skal I ansætte de første egne folk?
- Har I brug for en, der kan lede det tekniske arbejde?
Det skal I lade være med
- At lade leverancen være slutningen på aftalen · køb drift og vedligehold med, eller find en anden løsning.
- At fyre alle udviklere dagen efter lanceringen · der er altid noget, der skal rettes.
- At bruge al tid på nye funktioner · lad brugen vise, hvad I skal bygge.
Det skal I kræve af den eksterne
- ☐ En skriftlig liste over, hvem der ejer drift, opdateringer, fejlretning og support.
- ☐ En prøve på, at backup og gendannelse virker.
- ☐ En enkel plan for næste periode med plads til oprydning.
- ☐ Et klart svar på, hvad I selv kan klare, og hvad der kræver hjælp.
Kilder
- Kommissionens vejledning til Cyber Resilience Act, C(2026) 5252: ikke bindende, afsnit 2 om hvad der er omfattet.
- Europa-Kommissionen: underretning efter Cyber Resilience Act: pligten gælder siden 11/9 2026.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Backup af et SaaS-produkt: kan I faktisk genskabe det? · Sådan følger I fremdriften
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
