Så utvärderar du offerter på apputveckling
Utvärdera app-offerter genom att normalisera dem till samma omfattning innan du jämför pris: samma funktioner, antal plattformar, design, testning och förvaltning. Syna antaganden och friskrivningar — där göms skillnaderna — och ställ en skriftlig frågerunda till alla leverantörer före beslut. Slutsumman är det minst jämförbara talet i en offert.
Tre offerter på samma app: 650 000 kr, 1 100 000 kr och 1 750 000 kr. Vilken är billigast? Det går faktiskt inte att svara på än — för de tre leverantörerna har med största sannolikhet prissatt tre olika saker. Slutsumman är det minst jämförbara talet i en offert. Här är metoden för att jämföra det som går att jämföra.
Steg 1: Normalisera offerterna till samma omfattning
Bygg en enkel tabell där varje offert bryts ner mot samma poster. Saknas en post i en offert — fråga vad den kostar att lägga till, eller uppskatta den. Först därefter jämför du pris.
| Post att normalisera | Vanlig skillnad mellan offerter |
|---|---|
| Funktioner som ingår | En leverantör prissätter hela önskelistan, en annan bara "måsten" |
| Plattformar | iOS + Android, eller bara en? Nativt eller cross-platform? |
| Design | Färdiga komponenter kontra eget formspråk med användartester |
| Backend och admin | Ingår serverdel och adminpanel, eller antas de finnas? |
| Integrationer | Vilka system ingår, och vem bär risken om API:erna är sämre än väntat? |
| Testning och kvalitet | Egen post med budget, eller osynligt inbakad? |
| Lansering och butiker | App Store/Google Play-processen, granskningsrundor |
| Förvaltning efter lansering | Prissatt månadskostnad, eller "återkommer vi om"? |
| Projektledning | Ingår i timpriset eller egen post på 10–20 %? |
När allt räknats om till samma innehåll brukar spridningen krympa rejält — och ibland byter offerterna plats: den “dyraste” visar sig vara den enda som prissatt hela jobbet.
Steg 2: Syna antaganden och friskrivningar
Skillnaderna som återstår göms nästan alltid i det finstilta. Läs antagande- och avgränsningsavsnitten med penna:
- “Förutsätter att kunden tillhandahåller…” — API-dokumentation, testdata, innehåll, grafisk profil. Rimligt i sig, men vad händer med pris och tidplan om ni inte kan leverera i tid?
- “Ändringar hanteras som tilläggsbeställning.” Standard — men fråga vad timpriset är för tillägg och hur små ändringar som räknas. Här går marginalen att hämta hem för den som gav ett lågt grundpris.
- “Integration mot X förutsätter fungerande API.” Vem bär risken om API:et är odokumenterat eller instabilt? Den posten kan ensam svänga hundratusentals kronor.
- Antal korrekturrundor och testomfattning. “Design ingår” kan betyda en runda synpunkter — eller en iterativ process. “Testning ingår” kan betyda utvecklarnas egna tester — eller strukturerad QA på riktiga enheter.
- Vad som uttryckligen INTE ingår. Ofta den ärligaste och mest informativa delen av offerten. Saknas avsnittet helt är det inte för att allt ingår.
Steg 3: Frågerunda före beslut
Skicka samma skriftliga frågor till alla leverantörer och begär skriftliga svar — de blir del av avtalsunderlaget. Ett bra grundbatteri:
- Vilka är de tre största riskerna i projektet, och hur hanterar ni dem?
- Vad i er offert är mest osäkert prissatt, och åt vilket håll?
- Vilka personer bemannar projektet, och hur stor andel av sin tid?
- Vad kostar en typisk månad i förvaltning efter lansering?
- Om budgeten skulle behöva minska 20 procent — vad föreslår ni att vi stryker?
Svaren skiljer agnarna från vetet snabbare än någon prisjämförelse. Den som svarar konkret på fråga 2 och 5 förstår sitt eget estimat; den som svarar “inga större risker” har inte tänkt — eller berättar inte. Ge alla kandidater samma svarstid, och låt gärna svaren gå tillbaka in i normaliseringstabellen så att slutjämförelsen bygger på de justerade siffrorna.
Väg in det som inte står i offerten
Normaliseringen gör priserna jämförbara, men beslutet ska väga in mer: referenser, teamets seniority och hur leverantören agerat under själva offertprocessen. Ställde de frågor om er verksamhet? Utmanade de något i underlaget? En leverantör som redan i säljskedet hjälper er tänka bättre är ofta den som gör det i projektet också. Vi på Weapp tycker att en bra offert ska tåla exakt den här granskningen — hör av dig om du vill se hur vi bygger upp våra, eller läs mer om hur vi arbetar.
Vanliga frågor
Varför skiljer sig offerterna så mycket i pris?
Oftast för att de prissätter olika saker: olika tolkning av omfattningen, olika mycket design och testning, olika antaganden om era integrationer. Först när alla offerter räknats om till samma innehåll ser du de verkliga prisskillnaderna — de brukar vara mycket mindre än de såg ut.
Ska jag välja fastpris eller löpande räkning?
Fastpris ger förutsägbarhet men kräver att omfattningen verkligen är låst, och leverantören prisar in risken. Löpande räkning med budgettak och etappavstämningar ger flexibilitet när krav ändras — vilket de gör. För de flesta appprojekt är en etappindelad modell med tak den bästa kompromissen.
Är den dyraste offerten den bästa?
Inte nödvändigtvis, men den billigaste bygger oftare på de tunnaste antagandena — någon ska betala för det som inte prissattes, och det brukar bli beställaren via ändringsfakturor. Jämför vad som ingår, inte slutsumman. En offert med ärliga antaganden och synlig testbudget är ofta det bättre köpet.
Hur lång tid ska en offertutvärdering ta?
Räkna med 2–4 veckor från inkomna offerter till beslut: en vecka för normalisering och genomläsning, en för frågerunda och justerade svar, en för referenssamtal och slutförhandling. Det är kort tid i förhållande till att beslutet binder er vid en partner i ett år eller mer.
Vad gör jag om en offert är oklar på en viktig punkt?
Fråga skriftligt och begär skriftligt svar — svaret blir en del av avtalsunderlaget. En leverantör som svarar tydligt och justerar offerten visar hur den kommer hantera oklarheter i projektet. En som svarar undvikande på en direkt fråga i säljskedet blir inte tydligare efter kontraktet.