Vad kostar det att utveckla en app? Så läser du en offert innan du skriver på

Det här är den vanligaste frågan vi får, och den som får sämst svar överallt. Ni frågar tre leverantörer om samma app och får tre offerter som skiljer sig med en faktor tio. Ingen av dem ljuger. De har räknat på tre olika produkter, för ordet app betyder ingenting förrän det översatts till en lista funktioner.

Den här artikeln ger er inte en slutsumma — det kan ingen göra innan omfattningen finns. Den ger er något mer användbart: förmågan att läsa vilken offert som helst och se om den är rimlig.

All mjukvara prissätts likadant

Kostnaden är i princip antal arbetstimmar gånger timpris. Allt annat är detaljer. Och nästan hela prisskillnaden mellan offerter kommer från att parterna uppskattar helt olika antal timmar, eftersom de föreställer sig olika produkter.

Ta ett exempel. En bokningsapp kan betyda en skärm som visar lediga tider och skickar en förfrågan till er e-post. Den kan också betyda tre appar — kund, personal, administration — med betalning, kalendersynkronisering, påminnelser, avbokningsregler och en driftpanel. Första fallet är några veckors arbete. Andra fallet är ett halvår för ett team. Beskrivningen är densamma.

Därför är det första praktiska steget inte att begära offert, utan att skriva ned vad appen ska göra. Även en ofullständig lista halverar spridningen mellan offerterna. Hur en sådan skrivs finns i kravspecifikation som faktiskt fungerar.

Vad som driver kostnaden

Sex faktorer förklarar nästan hela skillnaden mellan en billig och en dyr app. De är värda att gå igenom innan ni pratar med någon, eftersom varje ja här kostar pengar.

1. Antal användartyper

Det här är den enskilt största posten och den som underskattas mest. En app med bara kunder är ett projekt. En app med kunder, personal och en administratör är i praktiken tre gränssnitt med tre uppsättningar behörigheter, och kostar därefter. Varje ny roll lägger till arbete i hela kedjan.

2. Egna konton och synkronisering

Ska användare logga in, ha egen data och se samma sak på flera enheter tillkommer registrering, inloggning, lösenordsåterställning, behörigheter och synkronisering. Det låter självklart och är sällan gratis.

3. Betalningar

Betalningar i appen betyder kortflöden, kvitton, återbetalningar, misslyckade betalningar och avstämning. Abonnemang lägger till förnyelser, uppsägningar och butikernas egna regler för köp i appen. Det är ett eget arbetspaket, inte en knapp.

4. Integrationer mot befintliga system

Varje system appen ska prata med — affärssystem, lager, CRM, ett bokningssystem ni redan har — är ett eget delprojekt. Har systemet ett dokumenterat API är det överskådligt. Har det inte det är det den post som oftast spränger en tidplan, och den ska prissättas separat med det uttalat.

5. Hur mycket som måste fungera utan uppkoppling

En app som ska vara användbar i källare, på tåg eller i en lagerlokal måste lagra data lokalt och lösa konflikter när den kommer online igen. Det är svårare än det låter och hör hemma i kravlistan tidigt, inte som en förbättring sedan.

6. Nivån av polering

Skillnaden mellan ett gränssnitt som fungerar och ett som känns genomarbetat är inte kosmetisk för kostnaden. Animationer, tomma tillstånd, felmeddelanden som hjälper, tillgänglighet och beteende på små skärmar är riktigt arbete. Det är ofta värt det — men det ska vara ett beslut, inte en överraskning.

Vad en offert måste vara nedbruten i

En offert som består av en summa går inte att jämföra med någon annan offert, och det är i regel inte en slump. Be om nedbrytning i minst dessa poster:

• Discovery och design — kravarbete, flöden, gränssnitt.
• Apputveckling per plattform, med det uttalat om det är en gemensam kodbas eller två.
• Backend och API — servern bakom appen.
• Administration — den webbpanel där ni sköter innehåll och ärenden. Glöms ofta och behövs alltid.
• Integrationer, en rad per system.
• Test och butikslansering — inklusive granskningen, som är där oförberedda projekt tappar veckor.
• Förvaltning efter lansering, som en löpande post och inte en engångssumma.

Saknas administrationen eller förvaltningen är offerten inte billigare än de andra. Den är ofullständig, och skillnaden dyker upp senare som ändringsbeställningar.

Fyra saker som inte är värda pengar i version ett

1. Funktioner för användare ni ännu inte har. Fleranvändarkonton, avancerade roller och exportfunktioner tillhör version två.
2. Egen inloggning där en färdig tjänst räcker. Identitetshantering är ett löst problem och sällan värt att bygga om.
3. Skalbarhet för volymer ni inte har. Arkitektur för hundratusentals användare kostar nu och används kanske aldrig.
4. Ett designsystem före första lanseringen. Det är rätt investering vid tredje produkten, inte vid den första.

Frågor som avslöjar mest på ett första möte

Ställ dessa och lyssna på hur de besvaras snarare än på svaret:

• Vad ingår inte i den här summan?
• Vilken post är ni mest osäkra på, och varför?
• Vad händer med priset om vi lägger till en användartyp?
• Vem äger kod, konton och certifikat efter leverans?
• Vad kostar förvaltningen per år?

En leverantör som inte kan peka ut sin egen osäkerhet har antingen inte tänkt igenom projektet eller tänker ta betalt för överraskningarna senare. Fler frågor att ställa finns i så väljer du utvecklingspartner.

Det billigaste sättet att sänka priset

Det är inte att förhandla timpriset. Det är att minska omfattningen. En avgränsning som halveras i ett möte sparar mer än någon rabatt gör, och den påverkar inte kvaliteten på det som byggs — bara mängden.

Det är hela idén bakom att börja med en avgränsad första version: bygg det minsta som kan ge ett riktigt svar på om produkten behövs, mät, och bygg vidare utifrån det. Se MVP och produktutveckling, eller apputveckling för hur ett helt projekt läggs upp.

Vill ni ha ett intervall för just er idé går det snabbast via ett kostnadsfritt möte: beskriv vad ni vill bygga, så säger vi vad vi ser och vad som ligger bakom siffran. Boka ett möte här.