Slik vurderer du tilbud på apputvikling
Vurder tilbud på apputvikling ved å normalisere dem til samme omfang før du sammenligner pris: samme funksjoner, antall plattformer, design, testing og forvaltning. Gå antakelser og forbehold etter i sømmene, for det er der forskjellene skjuler seg, og gjennomfør en skriftlig spørsmålsrunde med alle leverandørene før du bestemmer deg. Totalsummen er det minst sammenlignbare tallet i et tilbud.
Tre tilbud på samme app: 810 000 kr, 1,4 millioner kr og 2,18 millioner kr. Hvilket er billigst? Det er faktisk umulig å svare på ennå, for de tre leverandørene har med all sannsynlighet prissatt tre forskjellige ting. Totalsummen er det minst sammenlignbare tallet i et tilbud. Her er metoden for å sammenligne det som faktisk kan sammenlignes.
Steg 1: Normaliser tilbudene til samme omfang
Lag en enkel tabell der hvert tilbud brytes ned i de samme postene. Mangler en post i et tilbud, spør hva det koster å legge den til, eller anslå den selv. Først deretter sammenligner du pris.
| Post som skal normaliseres | Vanlig forskjell mellom tilbud |
|---|---|
| Funksjoner som er inkludert | Én leverandør prissetter hele ønskelisten, en annen bare «må ha» |
| Plattformer | iOS + Android, eller bare én? Native eller cross-platform? |
| Design | Ferdige komponenter kontra eget formspråk med brukertester |
| Backend og admin | Er serverdel og adminpanel inkludert, eller antas det at de finnes? |
| Integrasjoner | Hvilke systemer er med, og hvem bærer risikoen hvis API-ene er dårligere enn ventet? |
| Testing og kvalitet | Egen post med budsjett, eller usynlig bakt inn? |
| Lansering og appbutikker | Prosessen i App Store og Google Play, gjennomgangsrunder |
| Forvaltning etter lansering | Prissatt månedskostnad, eller «det kommer vi tilbake til»? |
| Prosjektledelse | Inkludert i timeprisen eller egen post på 10–20 %? |
Når alt er regnet om til samme innhold, pleier spredningen å krympe kraftig, og noen ganger bytter tilbudene plass: Det «dyreste» viser seg å være det eneste som har prissatt hele jobben.
Steg 2: Gå antakelser og forbehold etter i sømmene
Forskjellene som gjenstår, skjuler seg nesten alltid i det med liten skrift. Les avsnittene om antakelser og avgrensninger med blyanten i hånden:
- «Forutsetter at kunden leverer …» API-dokumentasjon, testdata, innhold, grafisk profil. Fornuftig i seg selv, men hva skjer med pris og tidsplan hvis dere ikke klarer å levere i tide?
- «Endringer håndteres som tilleggsarbeid.» Standard, men spør hvilken timepris som gjelder for tillegg, og hvor små endringer som teller. Det er her den som ga en lav grunnpris, kan hente inn marginen.
- «Integrasjon mot X forutsetter et fungerende API.» Hvem bærer risikoen hvis API-et er udokumentert eller ustabilt? Den posten alene kan svinge med hundretusenvis av kroner.
- Antall tilbakemeldingsrunder og testomfang. «Design er inkludert» kan bety én runde med innspill, eller en iterativ prosess. «Testing er inkludert» kan bety utviklernes egne tester, eller strukturert QA på fysiske enheter.
- Hva som uttrykkelig IKKE er inkludert. Ofte den ærligste og mest informative delen av tilbudet. Mangler avsnittet helt, er det ikke fordi alt er inkludert.
Steg 3: Spørsmålsrunde før beslutning
Send de samme skriftlige spørsmålene til alle leverandørene og be om skriftlige svar. De blir en del av avtalegrunnlaget. Et godt sett med grunnspørsmål:
- Hva er de tre største risikoene i prosjektet, og hvordan håndterer dere dem?
- Hva i tilbudet deres er prissatt med størst usikkerhet, og i hvilken retning?
- Hvilke personer skal bemanne prosjektet, og hvor stor andel av tiden sin?
- Hva koster en typisk måned med forvaltning etter lansering?
- Hvis budsjettet måtte ned med 20 prosent, hva foreslår dere at vi stryker?
Svarene skiller klinten fra hveten raskere enn noen prissammenligning. Den som svarer konkret på spørsmål 2 og 5, forstår sitt eget estimat. Den som svarer «ingen større risikoer», har ikke tenkt seg om, eller holder det for seg selv. Gi alle kandidatene samme svarfrist, og legg gjerne svarene inn i normaliseringstabellen slik at sluttsammenligningen bygger på de justerte tallene.
Ta med det som ikke står i tilbudet
Normaliseringen gjør prisene sammenlignbare, men beslutningen bør bygge på mer: referanser, hvor erfarent teamet er, og hvordan leverandøren har opptrådt i selve tilbudsprosessen. Stilte de spørsmål om hvordan dere driver virksomheten? Utfordret de noe i underlaget? En leverandør som allerede i salgsfasen hjelper dere å tenke bedre, er ofte den som gjør det i prosjektet også. Vi i Weapp mener at et godt tilbud skal tåle akkurat denne gjennomgangen. Ta kontakt hvis du vil se hvordan vi bygger opp våre, eller les mer om hvordan vi jobber.
Ofte stilte spørsmål
Hvorfor er det så store prisforskjeller mellom tilbudene?
Som oftest fordi de prissetter forskjellige ting: ulik tolkning av omfanget, ulik mengde design og testing, ulike antakelser om integrasjonene dere har. Først når alle tilbudene er regnet om til samme innhold, ser du de reelle prisforskjellene, og de pleier å være mye mindre enn det så ut til.
Skal jeg velge fastpris eller timepris?
Fastpris gir forutsigbarhet, men krever at omfanget virkelig er låst, og leverandøren legger risikoen inn i prisen. Avregning etter medgått tid, med budsjettak og kontrollpunkter mellom etappene, gir fleksibilitet når kravene endrer seg, og det gjør de. For de fleste apputviklingsprosjekter er en etappevis modell med tak det beste kompromisset.
Er det dyreste tilbudet det beste?
Ikke nødvendigvis, men det billigste bygger oftere på de spinkleste antakelsene. Noen må betale for det som ikke ble tatt med i prisen, og det pleier å bli kunden, via fakturaer for tilleggsarbeid. Sammenlign hva som er inkludert, ikke totalsummen. Et tilbud med ærlige antakelser og et synlig testbudsjett er ofte det beste kjøpet.
Hvor lang tid bør vurderingen av tilbudene ta?
Regn med 2–4 uker fra tilbudene er mottatt til beslutning: én uke til normalisering og gjennomlesning, én til spørsmålsrunde og justerte svar, én til referansesamtaler og sluttforhandling. Det er kort tid sett opp mot at beslutningen binder dere til en partner i ett år eller mer.
Hva gjør jeg hvis et tilbud er uklart på et viktig punkt?
Spør skriftlig og be om skriftlig svar. Svaret blir en del av avtalegrunnlaget. En leverandør som svarer tydelig og justerer tilbudet, viser hvordan den kommer til å håndtere uklarheter i prosjektet. En som svarer unnvikende på et direkte spørsmål i salgsfasen, blir ikke tydeligere etter at kontrakten er signert.