Sådan vurderer du tilbud på app-udvikling
Vurder tilbud på en app ved at normalisere dem til samme omfang før du sammenligner pris: samme funktioner, antal platforme, design, test og drift og vedligeholdelse. Gransk antagelser og forbehold, for det er dér forskellene gemmer sig, og send en skriftlig spørgerunde til alle leverandører før beslutningen. Slutsummen er det mindst sammenlignelige tal i et tilbud.
Tre tilbud på den samme app: 690.000 DKK, 1,2 mio. DKK og 1,86 mio. DKK. Hvilket er billigst? Det kan man faktisk ikke svare på endnu, for de tre leverandører har efter al sandsynlighed prissat tre forskellige ting. Slutsummen er det mindst sammenlignelige tal i et tilbud. Her er metoden til at sammenligne det der kan sammenlignes.
Trin 1: Normaliser tilbuddene til samme omfang
Byg en enkel tabel hvor hvert tilbud brydes ned på de samme poster. Mangler en post i et tilbud, så spørg hvad det koster at tilføje den, eller anslå den selv. Først derefter sammenligner du pris.
| Post der skal normaliseres | Typisk forskel mellem tilbud |
|---|---|
| Funktioner der er inkluderet | Én leverandør prissætter hele ønskelisten, en anden kun "must-haves" |
| Platforme | iOS + Android, eller kun én? Native eller cross-platform? |
| Design | Færdige komponenter over for et skræddersyet formsprog med brugertest |
| Backend og admin | Er serverdel og adminpanel inkluderet, eller antages de at findes? |
| Integrationer | Hvilke systemer er med, og hvem bærer risikoen hvis API’erne er dårligere end ventet? |
| Test og kvalitet | Egen post med budget, eller usynligt bagt ind? |
| Lancering og butikker | App Store/Google Play-processen, godkendelsesrunder |
| Drift og vedligeholdelse efter lanceringen | Prissat månedlig omkostning, eller "det vender vi tilbage til"? |
| Projektledelse | Inkluderet i timeprisen eller egen post på 10–20 %? |
Når alt er regnet om til samme indhold, plejer spredningen at skrumpe betydeligt, og nogle gange bytter tilbuddene plads: Det “dyreste” viser sig at være det eneste der har prissat hele opgaven.
Trin 2: Gransk antagelser og forbehold
De forskelle der er tilbage, gemmer sig næsten altid i det med småt. Læs afsnittene om antagelser og afgrænsninger med en pen i hånden:
- “Forudsætter at kunden leverer …” Det kan være API-dokumentation, testdata, indhold eller grafisk profil. Rimeligt i sig selv, men hvad sker der med pris og tidsplan hvis I ikke kan levere til tiden?
- “Ændringer håndteres som tillægsbestilling.” Det er standard, men spørg hvad timeprisen er for tillæg, og hvor små ændringer der tæller med. Her kan den der gav en lav grundpris, hente marginen hjem.
- “Integration med X forudsætter et fungerende API.” Hvem bærer risikoen hvis API’et er udokumenteret eller ustabilt? Den post alene kan svinge med hundredtusindvis af DKK.
- Antal korrekturrunder og testomfang. “Design er inkluderet” kan betyde én runde kommentarer eller en iterativ proces. “Test er inkluderet” kan betyde udviklernes egne test eller struktureret QA på rigtige enheder.
- Hvad der udtrykkeligt IKKE er inkluderet. Ofte den ærligste og mest informative del af tilbuddet. Mangler afsnittet helt, er det ikke fordi alt er med.
Trin 3: Spørgerunde før beslutningen
Send de samme skriftlige spørgsmål til alle leverandører, og bed om skriftlige svar. De bliver en del af aftalegrundlaget. Et godt sæt grundspørgsmål:
- Hvad er de tre største risici i projektet, og hvordan håndterer I dem?
- Hvad i jeres tilbud er mest usikkert prissat, og i hvilken retning?
- Hvilke personer bemander projektet, og med hvor stor en andel af deres tid?
- Hvad koster en typisk måned med drift og vedligeholdelse efter lanceringen?
- Hvis budgettet skulle skæres med 20 procent, hvad foreslår I så at vi dropper?
Svarene skiller fårene fra bukkene hurtigere end nogen prissammenligning. Den der svarer konkret på spørgsmål 2 og 5, forstår sit eget estimat. Den der svarer “ingen større risici”, har ikke tænkt over det eller fortæller det ikke. Giv alle kandidater den samme svartid, og lad gerne svarene gå tilbage i normaliseringstabellen så den endelige sammenligning bygger på de justerede tal.
Se også på det der ikke står i tilbuddet
Normaliseringen gør priserne sammenlignelige, men beslutningen skal bygge på mere: referencer, teamets senioritet og hvordan leverandøren har opført sig under selve tilbudsprocessen. Stillede de spørgsmål om jeres forretning? Udfordrede de noget i materialet? En leverandør der allerede i salgsfasen hjælper jer med at tænke bedre, er ofte den der også gør det i projektet. Hos Weapp mener vi at et godt tilbud skal kunne tåle netop denne granskning. Kontakt os hvis du vil se hvordan vi bygger vores op, eller læs mere om hvordan vi arbejder.
Ofte stillede spørgsmål
Hvorfor er der så stor prisforskel på tilbuddene?
Som regel fordi de prissætter forskellige ting: forskellig fortolkning af omfanget, forskellig mængde design og test, forskellige antagelser om jeres integrationer. Først når alle tilbud er regnet om til samme indhold, ser du de reelle prisforskelle, og de plejer at være meget mindre end de så ud til.
Skal jeg vælge fast pris eller afregning efter medgået tid?
Fast pris giver forudsigelighed, men kræver at omfanget virkelig er låst, og leverandøren prissætter risikoen ind. Afregning efter medgået tid med budgetloft og statusmøder ved hver etape giver fleksibilitet når kravene ændrer sig, og det gør de. For de fleste app-projekter er en etapeopdelt model med loft det bedste kompromis.
Er det dyreste tilbud det bedste?
Ikke nødvendigvis, men det billigste bygger oftere på de tyndeste antagelser. Nogen skal betale for det der ikke blev prissat, og det plejer at blive kunden via ændringsfakturaer. Sammenlign hvad der er inkluderet, ikke slutsummen. Et tilbud med ærlige antagelser og et synligt testbudget er ofte det bedre køb.
Hvor lang tid skal en vurdering af tilbud tage?
Regn med 2–4 uger fra tilbuddene er modtaget til beslutningen: en uge til normalisering og gennemlæsning, en til spørgerunde og justerede svar, en til referencesamtaler og slutforhandling. Det er kort tid set i forhold til at beslutningen binder jer til en partner i et år eller mere.
Hvad gør jeg hvis et tilbud er uklart på et vigtigt punkt?
Spørg skriftligt og bed om et skriftligt svar, for svaret bliver en del af aftalegrundlaget. En leverandør der svarer tydeligt og justerer tilbuddet, viser hvordan den vil håndtere uklarheder i projektet. En der svarer undvigende på et direkte spørgsmål i salgsfasen, bliver ikke tydeligere når kontrakten er underskrevet.