17 skjulte omkostninger i softwareprojekter (som tilbuddet ikke nævner)

Skjulte omkostninger i software er de udgifter der ikke står i udviklingstilbuddet, men som du alligevel ender med at betale: licenser, hosting, tredjeparts-API'er, ændringer undervejs, din egen tid og drift efter lanceringen. De fleste er ikke fup, bare poster som ingen har skrevet ned. Min tommelfingerregel er at lægge 15-30 % buffer oven i byggeprisen, afhængigt af hvor godt projektet er afklaret, og sætte 15-20 % af byggeprisen af om året til drift og vedligehold.

Den korte version: 17 poster og hvor meget de kan rykke

Jeg skriver selv tilbud som freelanceudvikler, så listen er også en påmindelse til mig selv om hvad der skal stå i dem. Tabellen samler alle 17 poster. Kolonnen til højre er min vurdering af hvor meget hver post typisk kan flytte budgettet på et mellemstort projekt, hvis ingen har regnet med den.

Læg mærke til at de poster der rykker mest, er dem der handler om arbejde og ikke om abonnementer. Vil du først vide hvad selve udviklingen koster, så start med prisguiden til softwareudvikling. Denne liste handler om alt det der ligger uden om.

Under projektet: de poster der vokser mens du bygger

De første seks poster opstår mens løsningen bliver bygget. De er de sværeste at sætte tal på, fordi de afhænger af hvor godt projektet er beskrevet, og hvor meget du ændrer mening undervejs.

1. Afklaringen som ingen har prissat

Et tilbud bygget på en halv sides beskrivelse og et enkelt møde er et kvalificeret gæt. Kravene bliver afklaret alligevel, bare midt i udviklingen, hvor hver ny beslutning kan betyde at noget skal bygges om. Du betaler for den afklaring uanset hvad. Den billigste måde at gøre det på er et kort forprojekt før udviklingen, hvor krav, skitser og estimat bliver skrevet ned. Hvad sådan et forløb koster, og hvad du får ud af det, står i guiden til prisen på en discovery-fase.

2. Ændringer undervejs

Når du ser de første skærme, får du nye idéer. Det er sundt, og det er også den mest almindelige grund til at et budget skrider. Ved timepris betaler du direkte for de ekstra timer. Ved fast pris bliver ændringer prissat for sig, ofte som tillægsaftaler. Spørg før start hvordan ændringer bliver estimeret og godkendt, og hvad timeprisen er på arbejde uden for aftalen. Hvem der bærer risikoen i de to modeller, har jeg gennemgået i sammenligningen af timepris og fastpris.

3. Din egen tid

Ingen udvikler kan bygge din løsning uden dig. Nogen skal svare på spørgsmål, godkende skærme, skaffe adgang til andre systemer og teste før lanceringen. Regn som udgangspunkt med et par timer om ugen for den der ejer projektet hos dig, og mere i ugerne op til lanceringen. Den tid står aldrig i et tilbud, men den koster løn, og den bliver ofte taget fra andre opgaver. Kan ingen hos dig afsætte tiden, er det bedre at vente med at starte.

4. Design, tekster og billeder

Mange tilbud forudsætter at du leverer design og indhold, eller at løsningen bygges med et standardbibliotek af knapper, formularer og tabeller. Står der "kunden leverer indhold", er det dig der skal skrive hjælpetekster, e-mails, fejlbeskeder, vilkår og eventuelle oversættelser. Skal en designer tegne skærmene fra bunden, er det en post for sig. Billeder fra en billedbank og skrifttyper kan også kræve en licens. Tjek hvad tilbuddet antager, og sæt en pris på det du selv skal levere.

5. Data fra det gamle system

Skal kunder, ordrer eller historik flyttes fra et regneark eller et ældre system, er det sjældent en simpel kopiering. Der er dubletter, felter der bliver brugt til noget andet end navnet siger, og huller som nogen skal tage stilling til. Selve importen kan gå hurtigt, men oprydningen og beslutningerne tager tid, både hos udvikleren og hos dig. Bed om at få datamigrering som sin egen linje i tilbuddet, og lad udvikleren se et udtræk af de rigtige data før prisen bliver sat.

6. Adgang til andre systemers API'er

En integration til dit økonomisystem, dit CRM eller dit lager ser enkel ud på en kravliste. I praksis kan den kræve et dyrere abonnement hos den anden leverandør for at åbne API'et (den adgang andre systemer bruger), en partneraftale, testkonti eller konsulenttimer hos dem. Dokumentationen kan være mangelfuld, og hver fejlsituation skal håndteres. Spørg leverandøren af det andet system hvad API-adgang koster, før du beder udvikleren om en pris på integrationen.

Licenser, hosting og tredjeparts-API'er

De næste seks poster er de klassiske skjulte omkostninger. De er sjældent store hver for sig, men de løber hver måned, og flere af dem vokser med antallet af brugere. Udvikleren kan ikke sætte en fast pris på dem, fordi de bliver betalt til andre.

7. Hosting og et testmiljø

Hosting er sjældent den store post, men den kommer hver måned: server, database, backup og et domæne der peger det rigtige sted hen. Mange glemmer at der også bør være et testmiljø (staging), hvor nye versioner bliver prøvet af før de går i drift. Det kan næsten fordoble serverudgiften. For en typisk webapp er det groft sagt et par hundrede til et par tusinde kroner om måneden. Aftal hvem der ejer hostingkontoen. Den bør stå i dit navn.

8. Tjenester der afregnes pr. forbrug

En moderne webapp lejer mange små dele: udsendelse af e-mails, SMS, kort, søgning, fejlovervågning og filopbevaring. Mange har en gratis grænse, og det gør dem billige i starten. Når brugerne kommer, stiger regningen. Bed udvikleren om en liste over alle tjenester løsningen bruger, hvad de koster i dag, og hvad de vil koste med ti gange så mange brugere. Så kan du se hvilke udgifter der vokser med forretningen, og hvilke der ligger fast.

9. Betalingsgebyrer

Tager du imod betaling i løsningen, tager betalingsudbyderen et gebyr pr. transaktion. Hos Stripe koster for eksempel et almindeligt kort udstedt i EØS 1,5 % + 1,80 kr. pr. betaling, og et internationalt kort 3,15 % + 1,80 kr., ifølge Stripes danske prisside. Hertil kommer tillæg for valutaomregning og eventuelle ekstra moduler til fakturaer eller abonnementer. Gebyret står aldrig i udviklerens tilbud, fordi det ikke er udviklerens, men det rammer din margin på hver eneste ordre.

10. AI-API'er

Bruger løsningen en sprogmodel fra fx OpenAI eller Anthropic, betaler du pr. forbrug, målt i tokens (små stykker tekst). En enkelt forespørgsel koster næsten ingenting, men en funktion som tusind brugere bruger hver dag, kan blive en mærkbar månedlig udgift. Prisen afhænger af modellen, hvor meget tekst der bliver sendt med, og hvor tit funktionen bliver brugt. Få lavet et skøn pr. bruger før du lancerer. Jeg har regnet eksempler igennem i guiden til hvad AI koster i drift.

11. Licenser til pakker, skrifttyper og værktøjer

Det meste af det udviklere bygger med, er gratis open source. Men nogle pakker, komponentbiblioteker, administrationspaneler og skrifttyper kræver en betalt licens, og nogle skal fornyes hvert år for at give adgang til opdateringer. Spørg hvilke betalte licenser løsningen bruger, hvem de er købt i navnet på, og hvad der sker hvis de ikke bliver fornyet. En licens i udviklerens navn bliver et problem den dag I går hver til sit.

12. Domæner, app stores og udviklerkonti

Små beløb, men de skal betales og fornyes. Et domæne koster et årligt gebyr. Skal der være en app i App Store, kræver Apple et medlemskab af Apple Developer Program til 99 dollar om året, og Google tager et engangsgebyr på 25 dollar for en udviklerkonto på Google Play. Sælger du noget inde i appen, tager platformene typisk også en andel af salget. Opret kontiene i virksomhedens navn fra starten, så du ikke skal flytte apps mellem konti senere.

Efter lanceringen: driften som ingen regnede med

Lanceringen er ikke den sidste regning. De sidste fem poster kommer når løsningen er i drift, og de er de letteste at glemme, fordi de ikke hører til selve projektet.

13. Opdateringer og sikkerhedsrettelser

Software ældes, selvom ingen ændrer i koden. Frameworks, pakker og serversoftware får sikkerhedsrettelser, og ældre versioner holder op med at få dem. Laravel udgiver en ny hovedversion hvert år, og hver version får fejlrettelser i 18 måneder og sikkerhedsrettelser i to år, ifølge Laravels supportpolitik. Små, løbende opdateringer er billige. Et spring over flere versioner er et projekt i sig selv, som du kan se i guiden til prisen på en Laravel-opgradering.

14. Fejlrettelser efter lanceringen

Rigtige brugere finder fejl som ingen test fandt. Spørgsmålet er hvem der betaler. Nogle tilbud indeholder en periode hvor fejl i det leverede bliver rettet uden beregning, andre gør ikke. Få skrevet ind hvor lang perioden er, hvad der tæller som en fejl, og hvad der er et nyt ønske. "Knappen virker ikke" er en fejl. "Knappen burde gøre noget andet" er en ændring, og den koster.

15. Overvågning, backup og vagt

Hvem opdager det når løsningen går ned en søndag aften? Overvågning, fejlrapportering og backup kræver opsætning, ofte et lille abonnement og nogen der reagerer. En backup er først noget værd når nogen har prøvet at gendanne den. Skal nogen svare uden for almindelig arbejdstid, er det en aftale for sig, og den koster mere end hjælp på hverdage. Mange har ikke brug for vagt, men det skal være et valg og ikke en overraskelse.

16. Sikkerhed og persondata

Behandler løsningen persondata, skal du have databehandleraftaler med de tjenester der opbevarer data for dig, styr på hvem der har adgang til hvad, og en plan for hvad der sker ved et sikkerhedsbrud. Noget af det er udviklerens arbejde, fx logning og sletning af data. Andet er dit, fx at opdatere privatlivspolitikken. Større eller følsomme systemer kan også have brug for en ekstern sikkerhedstest. Den slags krav er billigst at kende før udviklingen starter.

17. Overdragelse og skift af udvikler

Den dag du skifter udvikler eller ansætter din egen, skal den nye sætte sig ind i koden. Uden dokumentation, adgang og en ordentlig overdragelse kan der gå uger før den nye kan levere noget. Det er en udgift du betaler sent, men den bliver bestemt tidligt. Sørg for at koden ligger i dit eget repository (kodearkiv) fra første dag, at alle konti står i dit navn, og at dokumentation er en del af leverancen. Hos mig ejer kunden koden fra første dag, og det bør være standard hos enhver leverandør.

Sådan lægger du buffer i budgettet

Du kan ikke sætte præcise tal på alle 17 poster på forhånd. Det du kan, er at give dem plads i budgettet. Sådan anbefaler jeg at du lægger rammen:

• Buffer på udviklingen: 15 % hvis der har været et forprojekt, og omfanget er skrevet ned. 25-30 % hvis projektet kun er løst beskrevet, eller hvis der er integrationer til systemer som ingen har arbejdet med før.
• Også ved fast pris: udvikleren har sin egen buffer i prisen, men ændringer og alt uden for aftalen kommer oveni. Sæt mindst 10 % af til det.
• Engangsposter som egne linjer: tekster, licenser, datarydning og konti hører ikke hjemme i bufferen. Skriv dem op hver for sig.
• Drift fra dag ét: 15-20 % af byggeprisen om året til hosting, tjenester, opdateringer og små forbedringer.

Her er et tænkt eksempel på et projekt med et tilbud på 250.000 kr., hvor kravene er nogenlunde beskrevet, men hvor der ikke har været et forprojekt. Tallene er ikke fra et rigtigt projekt, men forholdet mellem posterne er typisk.

Et tilbud på 250.000 kr. bliver altså til et realistisk budget på godt 350.000 kr. det første år, før din egen tid er regnet med. Det lyder voldsomt, men det er den pris projektet havde i forvejen. Forskellen er at du kender den før du skriver under.

Hvornår regnestykket taler for en standardløsning

Lægger du alle 17 poster sammen, kan det vende regnestykket. Et standardsystem du betaler for hver måned, har hosting, opdateringer, backup og support med i prisen. Dækker det omkring 80 % af dine behov, er det ofte billigere over tre til fem år end at bygge selv, også når abonnementet virker dyrt pr. bruger. Sammenlign derfor de samlede udgifter over fem år, ikke byggepris mod månedspris.

Standardsystemer har også skjulte poster: pris pr. bruger der stiger med væksten, betalte tilføjelser og data der kan være svære at få med ud igen. Udvikling fra bunden betaler sig når løsningen understøtter noget der er særligt for din forretning, eller når licenserne over nogle år koster mere end at eje løsningen selv.

Er dit budget kun lige nok til selve udviklingen, uden plads til buffer og drift, så er det et tegn på at du skal starte mindre eller vælge en standardløsning. Det er ikke et tegn på at du skal finde en billigere udvikler.

Næste skridt

Tag det tilbud du har fået, eller den idé du går med, og gå listen igennem. Skriv ud for hver post om den er med i prisen, om den ikke er relevant, eller om du skal spørge. De spørgsmål der står tilbage, kan du sende direkte til udvikleren.

Har du flere tilbud at vælge imellem, så brug metoden til at sammenligne tilbud fra udviklere, så du sammenligner på samme grundlag. Hvordan jeg selv prissætter forprojekt, udvikling og løbende aftaler, kan du se på min side med priser.

Ofte stillede spørgsmål

Er skjulte omkostninger et tegn på en uærlig udvikler?+

Sjældent. De fleste skjulte omkostninger er udgifter som udvikleren ikke selv modtager, fx hosting, gebyrer og licenser, eller arbejde der afhænger af beslutninger som endnu ikke er truffet. Advarselstegnet er et tilbud uden fravalg og antagelser. Så ved du ikke hvad du har købt, og du opdager hullerne først når de første ekstraregninger kommer.

Skal hosting og tjenester stå i mit eller udviklerens navn?+

I dit navn, så vidt muligt. Når kontiene står i virksomhedens navn og bliver betalt med jeres kort, har du kontrollen hvis samarbejdet stopper, og du kan se præcis hvad du betaler. Nogle udviklere videresælger hosting med et tillæg for at stå for driften. Det kan være fint, så længe du ved det, og så længe du kan få kontiene overdraget.

Kan jeg få en fast månedlig pris på drift og vedligehold?+

Ja, mange udviklere tilbyder en fast månedlig aftale der dækker opdateringer, overvågning, backup og et antal timer til små rettelser. Forbrugsafregnede tjenester som e-mail, SMS, betaling og AI bliver typisk faktureret for sig, fordi de svinger med antallet af brugere. Spørg hvad der sker med ubrugte timer, og hvad timeprisen er når aftalens timer er brugt.

Hvordan håndterer jeg moms på tjenester fra udlandet?+

Køber din virksomhed tjenester fra udlandet, fx et amerikansk abonnement, skal du som regel selv beregne og afregne dansk moms efter reglerne om omvendt betalingspligt. Er virksomheden momsregistreret med fuld fradragsret, går det typisk lige op, men det skal bogføres korrekt. Mange tjenester fakturerer desuden i dollar, så prisen svinger med kursen. Tal med din revisor om din konkrete situation.