Slik setter du et budsjett for apputvikling

De fleste appbudsjetter settes baklengs: Noen nevner en sum, summen blir budsjettet, og så forhandles innholdet til det «får plass». En bedre måte er å bygge budsjettet slik byråene selv regner, med en fordelingsnøkkel, en ærlig kalkyle for år 2 og en buffer som får være i fred. Her er malen.

Begynn med fordelingsnøkkelen

Enten budsjettet er 620 000 eller 3,7 millioner, fordeler et godt styrt approsjekt seg omtrent likt:

Nøkkelen har to poenger. Det første: Du ser med en gang om et tilbud er komplett. Hvis utviklingen er priset til 750 000 kr, men design, prosjektledelse og testing mangler, er den reelle totalen nærmere 1,2 millioner. Det andre: Du kan regne baklengs. Har du 1 million kr totalt, vet du at utviklingsdelen kan koste omtrent 500 000–600 000 kr, og du kan vurdere omfanget opp mot det.

Nøkkelen gjelder prosjekter i det normale spennet. Små oppdrag som en prototype er designtunge og kan ligge på 40 prosent design, mens store systemprosjekter trekker mot mer utvikling og QA. Bruk fordelingen som utgangspunkt, og be byrået begrunne avvik. Den samtalen avslører raskt hvor gjennomtenkt tilbudet er.

Regn med år 2 fra dag én

En app slutter ikke å koste når den lanseres. Det er da det begynner. Tre løpende poster skal inn i kalkylen fra start:

• Vedlikehold: 15–25 prosent av utviklingskostnaden per år. Nye OS-versjoner, oppdaterte avhengigheter, feilrettinger.
• Drift: typisk 1 900–19 000 kr i måneden for servere og tredjepartstjenester.
• Videreutvikling: det brukerne kommer til å be om. Selv et beskjedent tempo koster noen hundre tusen kroner i året.

Grunnen til å ta det nå er ikke pedanteri. En app som bygges for hele investeringsbudsjettet og deretter står uten penger til forvaltning, forfaller i løpet av et par år, og da er hele investeringen truet, ikke bare år 2. En enkel regel som hjelper: Ingen beslutning om å bygge noe godkjennes uten at den tilsvarende raden for år 2 er fylt ut. Det tar ti minutter per beslutning og holder totalkalkylen ærlig gjennom hele prosjektet.

De tre vanligste budsjettfeilene

Etter mange approsjekter ser vi i Weapp de samme tre feilene gå igjen hos kunder:

1. Hele budsjettet går til versjon 1. Ingenting er igjen til forvaltning, drift eller de forbedringene brukerne etterspør med en gang. Løsning: Sett av 20–30 prosent av den totale rammen til året etter lansering.
2. Bufferen blir en idépott. Bufferen spises opp av «kan vi også få»-ønsker midt i prosjektet, og når et virkelig problem dukker opp, er den borte. Løsning: Nye ideer legges på en liste til versjon 2, og bufferen brukes bare til uforutsette problemer.
3. Tilbud sammenlignes på utviklingstimer. Det billigste tilbudet mangler ofte design, prosjektledelse og testing, poster som utgjør 30–40 prosent av et reelt prosjekt. Løsning: Sammenlign alltid totalpris for det samme innholdet, med fordelingsnøkkelen som fasit.

Regneeksempel: budsjett på 1,5 millioner

La oss si at ledelsen har satt av 1,5 millioner til en kundeapp. Med nøkkelen blir byggingen slik: design 220 000–300 000 kr, utvikling 750 000–900 000 kr, prosjektledelse og QA 220 000–300 000 kr samt buffer 150 000–220 000 kr. I tillegg kommer årlige kostnader fra år 2: vedlikehold rundt 190 000–310 000 kr og drift 48 000–140 000 kr. Den ærlige treårskalkylen for satsingen er altså snarere 2,1–2,7 millioner enn 1,5, og det er det tallet som skal forankres, ikke byggekostnaden.

Fra budsjett til tilbud

Med en fordelingsnøkkel, en post for år 2 og en skjermet buffer har du et budsjettgrunnlag som holder både overfor styret og i forhandlingene med byrået. Be dessuten hvert byrå om å sette opp tilbudet sitt etter de samme fire postene, altså design, utvikling, prosjektledelse og QA samt buffer, så blir sammenligningen virkelig ærlig. Neste steg er å teste budsjettet mot virkeligheten: En forstudie prissetter det faktiske omfanget ditt, og derfra kan budsjettet justeres ut fra fakta i stedet for magefølelse. Vil du ha hjelp til å regne på ideen din, er det bare å ta kontakt.