Hva en skreddersydd app egentlig koster: en ærlig og transparent oppdeling

Spør tre byråer hva en skreddersydd app koster, og du får tre tall som ikke engang deler ett eneste siffer. Ett sier fire tusen, ett sier førti, ett sier lavmælt at det kommer an på og booker et nytt møte. Ingen av dem lyver, egentlig — men ingen av dem forteller deg det du faktisk trenger å vite, nemlig hvor pengene går, og hvorfor akkurat din app lander der den lander. Så la oss åpne panseret.

Jeg har skrevet flere app-tilbud enn jeg kan telle, for bedrifter fra en énmannshåndverker til en regional kjede. Den klart vanligste reaksjonen på en pris er ikke sjokk over totalen — det er forvirring over spennet. Hvordan kan den samme tre-ords briefen («en bookingapp») gi estimater som skiller seg med en faktor ti? Det ærlige svaret er at «en bookingapp» ikke er en brief. Det er et ønske. Prisen bor i de hundre små beslutningene som gjemmer seg under den.

Denne teksten er oppdelingen jeg skulle ønske at enhver bedriftseier hadde hatt før sin første samtale med en utvikler. Ingen fyllstoff, ingen skremselstaktikk, ingen mersalg. Bare de reelle kostnadspostene, tingene som lavmælt dobler et budsjett, og noen ærlige måter å bruke mindre på uten å ende opp med noe du angrer på.

Hvorfor to tilbud på «den samme appen» skiller seg med 10x

Programvare er ikke et produkt du tar ned fra en hylle — det er arbeid, målt i timene til dyktige mennesker. Så prisen på en skreddersydd app er i bunn og grunn bare omfang × timepris × risiko. Alt annet er en fotnote til de tre tingene. Når to tilbud spriker voldsomt, leses ett av disse tre tallene svært ulikt, og som regel har ingen sagt det høyt.

Omfang er det åpenbare. «En bookingapp» kan bety en enkelt skjerm der kunder velger et tidspunkt — eller det kan bety personalkalendere, betalinger, påminnelser, kundeinnlogging, et admin-dashbord, refusjoner og en rapport eieren leser på mandag. Samme tre ord, ti ganger arbeidet. Det billige tilbudet antar ofte den lille versjonen; det dyre antar lavmælt den store. Ingen av dem spurte hvilken du mente.

Så er det risikoen, den delen ingen liker å prissette. En vag brief, en kunde som ikke har bestemt seg for hva den vil ha, en integrasjon med et knirkete gammelt system — disse legger ikke bare til timer, de legger til usikkerhet. Erfarne team legger på en buffer for usikkerhet fordi de har brent seg på den. Et billigere tilbud har ofte ikke prissatt risikoen i det hele tatt, noe som er nettopp derfor det noen ganger svulmer opp halvveis ut i prosjektet.

Hvor pengene faktisk går

Når folk ser for seg apputvikling, ser de for seg koding. Koding er reelt, men det er sjelden engang halve regningen. En skreddersydd app er nærmere det å bygge et lite hus enn å skrive et dokument — det er design, rørlegging, kontroll og papirarbeid rundt den synlige delen. Slik deles et typisk budsjett opp når du regner inn alt.

To ting pleier å overraske folk i den tabellen. For det første hvor mye av budsjettet som skjer før en eneste linje funksjonskode er skrevet — kartlegging og design er ikke luksus, de er det billigste stedet å rette en feil. Å endre en skjerm i en skisse koster minutter; å endre den etter at den er bygget koster dager. For det andre hvor reell testlinjen er. Å hoppe over den sparer ikke penger, den flytter bare kostnaden til lanseringsuken din, med renter.

Kartlegging og design: delen alle vil hoppe over

Kartlegging er der du gjør «en bookingapp» om til en presis liste over skjermer og regler. Det føles som overhead fordi ingenting bygges ennå. Men hver time her sparer flere lenger fremme, fordi det er her tvetydighet drepes mens den fortsatt er billig. Et team som gir deg en pris uten en kartleggingsfase, enten gjetter eller planlegger å fakturere deg for kartleggingen senere under et annet navn.

Kjerneutvikling: den synlige motoren

Dette er koden som får idéen din til å kjøre — skjermene folk trykker på, logikken bak dem, og databasen som lavmælt husker alt. Det er den største enkeltbiten, og den skalerer nesten direkte med omfanget. Hver funksjon du legger til er mer å bygge, mer å teste og mer å vedlikeholde for alltid. Dette er linjen der «ville det ikke vært fint om» raskt blir dyrt.

Integrasjoner: den bedragersk dyre delen

Å koble appen din til andre systemer — ta imot en kortbetaling, sende en SMS-påminnelse, synkronisere en kalender, hente data fra regnskapsprogrammet du allerede bruker — ser lite ut på en funksjonsliste og lander overraskende tungt på fakturaen. Hver tilkobling er et lite prosjekt i seg selv, med sine egne særegenheter og feilmoduser. Én veloppdragen betalingsintegrasjon er grei. Fem sammenfiltrede integrasjoner med et aldrende internt system er der budsjetter går for å dø.

Kostnadene ingen setter i tilbudet

Her får mange eiere en ufyselig overraskelse tolv måneder inn. Bygget er et engangstall; en app er ikke en engangsting. Programvare er levende — telefoner oppdateres, regler endres, bedriften din vokser — og en levende ting må mates. Tilbudet du signerer er prisen for fødselen, ikke prisen for eierskapet.

Ingenting av dette er svindel eller en skjult felle — det er bare delen som ikke passer pent på et énsides tilbud, så svakere partnere utelater den for å se billigere ut. En god forteller deg om den på forhånd, selv om det får det første tallet til å se større ut. Spør eksplisitt: hva koster det meg å drive dette i ett år etter lansering? Kvaliteten på svaret forteller mye om hvem du har med å gjøre.

Hva som lavmælt dobler prisen

Noen ting legger til kostnad i forhold til verdien de gir — greit nok. Andre legger til kostnad helt ute av proporsjoner, vanligvis på grunn av hvordan arbeidet er strukturert snarere enn hva appen gjør. Dette er spakene verdt å forstå, fordi noen av dem er helt innenfor din kontroll.

• To plattformer i stedet for én. En nativ iPhone-app og en nativ Android-app er, grovt sagt, to bygg. Tverrplattform-verktøy eller en webapp kan trekke det tilbake mot ett. Dette ene valget kan flytte totalen mer enn noen funksjon.
• Skreddersydd design fremfor fornuftige standarder. Et pikselperfekt, fullstendig skreddersydd grensesnitt koster ekte penger å designe og bygge. Et rent, konvensjonelt som bruker velprøvde mønstre er raskere, billigere og ofte lettere for kunder å bruke.
• Å ombestemme deg etter at bygget har startet. Beslutninger er billige på en tavle og dyre i kode. Den vanligste budsjettoverskridelsen er ikke dårlig estimering — det er omfang som fortsatte å vokse fordi ingenting ble spikret.
• Sanntid, frakoblet eller tunge data. «Det må virke uten signal» eller «oppdateringer må vises umiddelbart for alle» er rimelige ønsker som lavmælt mangedobler ingeniørarbeidet under.
• Å integrere med noe gammelt og udokumentert. Å koble til et moderne, godt bygget system er rutine. Å koble til et femten år gammelt internt verktøy uten dokumentasjon er arkeologi, og det faktureres per time.

Et virkelig eksempel: tilbudet på 60 000 € som ble en app til 14 000 €

Noen detaljer er endret av hensyn til personvern, men formen på dette er sann og helt typisk. En regional servicebedrift — tenk et dusin feltarbeidere og et travelt kontor — kom til oss frustrerte. De ville ha en skreddersydd app der kundene deres kunne bestille oppdrag, følge fremdrift og betale. De hadde allerede fått et tilbud et annet sted på rundt 60 000 €, pluss en solid månedlig avgift, og det hadde skremt dem fra hele idéen i den bedre delen av et år.

Da vi faktisk kartla hva de trengte — ikke hva de hadde fått tilbud på — så bildet svært annerledes ut. Det første tilbudet hadde antatt to fullt native apper, et skreddersydd design fra bunnen, et sanntidssystem for oppdragsfordeling og en skreddersydd admin-plattform for å erstatte verktøy de allerede eide og lavmælt var fornøyde med. Det var, teknisk sett, en helt utmerket app. Det var også et svar på et spørsmål de ikke hadde stilt.

Hva vi faktisk gjorde

Vi brukte de første øktene på ren kartlegging — å plukke ønsket fra hverandre i «bedriften bryter sammen uten dette» mot «det hadde vært fint en gang». Må-haves var smalere enn noen hadde ventet: en ren måte for kunder å be om og følge et oppdrag, automatiske påminnelser og nettbetaling. Sanntidsfordelingen og det skreddersydde backoffice viste seg å være løsninger på problemer den eksisterende programvaren deres allerede håndterte greit.

1. 1
   Kuttet omfanget til den reelle jobben

   Vi droppet funksjonene som løste problemer de ikke hadde, og beholdt en stram liste bedriften oppriktig ikke kunne drive uten.
2. 2
   Valgte ett tverrplattform-bygg

   I stedet for to separate native apper dekket én enkelt tverrplattform-app både iPhone og Android — noe som omtrent halverte kjerneutviklingen.
3. 3
   Brukte velprøvde designmønstre

   Et rent, konvensjonelt grensesnitt i stedet for et skreddersydd. Kundene fant det lettere å bruke, og det barberte uker av tidslinjen.
4. 4
   Koblet til, erstattet ikke

   Vi koblet appen til kontorprogramvaren de allerede betalte for, i stedet for å bygge den på nytt. Den dyre «skreddersydde admin-plattformen» forsvant rett og slett ut av omfanget.

Resultatet ble et bygg på rundt 14 000 €, i drift på noen måneder, med løpende kostnader de kunne forutse. Den er ikke like vidtfavnende som 60 000 €-versjonen — og den trenger ikke å være det. Den gjør jobben bedriften faktisk hadde. Et år senere har de lagt til to små funksjoner oppå, betalt med pengene den første versjonen sparte dem. Det er hele mønsteret: start med den reelle jobben, fortjen ekstrafunksjonene med resultater.

Hvordan holde kostnaden fornuftig uten å ta snarveier

Å bruke mindre på en skreddersydd app handler ikke om å prute timeprisen ned eller finne det billigste teamet du kan. Slik ender du opp med å betale dobbelt. Det handler om å være bevisst med omfang, rekkefølge og beslutninger — de tre tingene som oppriktig flytter tallet. Her bor de reelle besparelsene.

For det første, bygg den minste versjonen som faktisk er nyttig, og la den så vokse. En fokusert første lansering som gjør én ting godt, får deg i drift raskere, koster en brøkdel av alt-i-ett-drømmen og — avgjørende — lærer deg hva du skal bygge videre fra ekte kunder i stedet for gjetninger. For det andre, ta beslutningene dine før bygget starter; ubesluttsomhet er det dyreste du kan bringe til et prosjekt. For det tredje, koble til det du allerede eier i stedet for å erstatte fungerende verktøy, og bygg bare noe på nytt når det oppriktig holder deg tilbake.

Vanlige spørsmål