Sådan lægger du et budget for app-udvikling
Læg app-budgettet med en fordelingsnøgle i stedet for et samlet beløb: design 15–20 procent, udvikling 50–60, projektledelse og kvalitetssikring 15–20 samt en buffer på 10–15 procent. Tag desuden år 2 med i regnestykket fra start (vedligeholdelse, drift og videreudvikling), så slipper du for den mest almindelige overraskelse: en app der står uden penge efter lanceringen.
De fleste app-budgetter bliver lagt baglæns: Nogen nævner et beløb, beløbet bliver budgettet, og så forhandles indholdet indtil det “kan være der”. En bedre måde er at bygge budgettet op sådan som bureauerne selv regner: med en fordelingsnøgle, et ærligt regnestykke for år 2 og en buffer der får lov at være i fred. Her er skabelonen.
Start med fordelingsnøglen
Uanset om budgettet er 530.000 DKK eller 3,2 mio. DKK, fordeler et velstyret app-projekt sig nogenlunde ens:
| Budgetpost | Andel | Hvad der indgår |
|---|---|---|
| Design og forundersøgelse | 15–20 % | Kravbillede, UX, brugerflade, prototype |
| Udvikling | 50–60 % | App, backend, integrationer |
| Projektledelse og QA | 15–20 % | Styring, test, kvalitetssikring |
| Buffer | 10–15 % | Ukendte problemer, ikke nye idéer |
Nøglen har to pointer. Den første: Du ser med det samme om et tilbud er komplet. Er udviklingen prissat til 640.000 DKK i tilbuddet, men mangler design, projektledelse og test, er den reelle total snarere 1,1 mio. DKK. Den anden: Du kan regne baglæns. Har du 850.000 DKK i alt, ved du at udviklingsdelen må koste cirka 430.000–510.000 DKK, og du kan tilpasse omfanget til det.
Nøglen gælder projekter i det normale spænd. Små opgaver som en prototype er designtunge og kan ligge på 40 procent design mens store systemprojekter trækker mod mere udvikling og QA. Brug fordelingen som udgangspunkt, og bed bureauet om at begrunde afvigelser. Den samtale afslører hurtigt hvor gennemtænkt tilbuddet er.
Regn med år 2 fra dag ét
En app holder ikke op med at koste når den lanceres. Det er dér den begynder. Tre løbende poster skal med i regnestykket fra start:
- Vedligeholdelse: 15–25 procent af udviklingsomkostningen om året. Nye versioner af styresystemerne, opdaterede afhængigheder, fejlrettelser.
- Drift: typisk 1.300–13.000 DKK om måneden til servere og tredjepartstjenester.
- Videreudvikling: det brugerne kommer til at bede om. Selv et beskedent tempo koster nogle hundredtusinde DKK om året.
Grunden til at tage det med nu er ikke pedanteri. En app der bygges for hele investeringsbudgettet og derefter står uden penge til drift og vedligeholdelse, forfalder inden for et par år, og så er hele investeringen truet, ikke kun år 2. En enkel regel der hjælper: Ingen beslutning om at bygge noget godkendes uden at den tilsvarende linje for år 2 er udfyldt. Det tager ti minutter pr. beslutning og holder det samlede regnestykke ærligt gennem hele projektet.
De tre mest almindelige budgetfejl
Efter mange app-projekter ser vi hos Weapp de samme tre fejl gå igen hos kunderne:
- Hele budgettet går til version 1. Intet tilbage til vedligeholdelse, drift eller de forbedringer brugerne straks efterspørger. Løsning: Afsæt 20–30 procent af den samlede ramme til året efter lanceringen.
- Bufferen bliver en idépulje. Bufferen bliver spist op af “kan vi også få”-ønsker midt i projektet, og når et rigtigt problem dukker op, er den væk. Løsning: Nye idéer kommer på en liste til version 2; bufferen bruges kun til uforudsete problemer.
- Tilbud sammenlignes på udviklingstimer. Det billigste tilbud mangler ofte design, projektledelse og test, poster der udgør 30–40 procent af et rigtigt projekt. Løsning: Sammenlign altid totalprisen for det samme indhold, med fordelingsnøglen som facit.
Regneeksempel: et budget på 1,3 mio. DKK
Lad os sige at ledelsen har afsat 1,3 mio. DKK til en kundeapp. Med nøglen ser selve projektet sådan ud: design 190.000–260.000 DKK, udvikling 640.000–770.000 DKK, projektledelse og QA 190.000–260.000 DKK samt buffer 130.000–190.000 DKK. Oven i det kommer årlige omkostninger fra år 2: vedligeholdelse cirka 160.000–270.000 DKK og drift 33.000–100.000 DKK. Det ærlige treårsregnestykke for satsningen er altså snarere 1,7–2 mio. DKK end 1,3 mio. DKK, og det er det tal der skal forankres, ikke udviklingsomkostningen.
Fra budget til tilbud
Med en fordelingsnøgle, en post for år 2 og en fredet buffer har du et budgetgrundlag der holder både over for bestyrelsen og i forhandlingen med bureauerne. Bed desuden hvert bureau om at opstille sit tilbud efter de samme fire poster (design, udvikling, projektledelse og QA samt buffer), så bliver sammenligningen ærlig for alvor. Næste skridt er at teste budgettet mod virkeligheden: En forundersøgelse prissætter dit faktiske omfang, og derfra kan budgettet justeres ud fra fakta i stedet for mavefornemmelse. Vil du have hjælp til at regne på din idé, så kontakt os.
Ofte stillede spørgsmål
Hvor stor en buffer har et app-projekt brug for?
Regn med 10–15 procent af det samlede budget. Har projektet uklare krav, mange integrationer eller en teknologi teamet ikke har brugt før, bør bufferen ligge i den øvre ende. Bufferen er til ukendte problemer, ikke til nye idéer der dukker op undervejs.
Hvad koster en app om året efter lanceringen?
En almindelig tommelfingerregel er 15–25 procent af udviklingsomkostningen om året til vedligeholdelse og mindre videreudvikling plus driftsomkostninger på typisk 1.300–13.000 DKK om måneden. For en app der kostede 1,1 mio. DKK at bygge, betyder det groft sagt 210.000–320.000 DKK om året.
Skal markedsføring med i app-budgettet?
Den skal med i det samlede regnestykke, men som en særskilt post, adskilt fra udviklingen. En app uden lanceringsplan får sjældent brugere af sig selv. Hvor stor posten skal være, afhænger helt af målet: En intern app behøver slet ingen markedsføring; en forbrugerapp kan have brug for mere end udviklingsbudgettet.
Hvordan præsenterer jeg budgettet for ledelsen eller bestyrelsen?
Vis den samlede omkostning over to til tre år (udvikling, vedligeholdelse, drift og videreudvikling) i stedet for kun udviklingsomkostningen. Det giver et ærligt beslutningsgrundlag og sparer dig for at bede om flere penge seks måneder efter lanceringen, hvilket er det scenarie bestyrelser bryder sig mindst om.
Kan jeg dele projektet op i etaper for at sprede omkostningen?
Ja, og det er ofte klogt: en første version med kerneflowene og derefter etaper styret af den faktiske brug. Behold fordelingsnøglen inden for hver etape, og lås dig ikke fast i en stor samlet plan. Lad data fra etape et styre indholdet i etape to.