Hvad en skræddersyet app virkelig koster: en ærlig og gennemsigtig opdeling

Spørg tre bureauer, hvad en skræddersyet app koster, og du får tre tal, der ikke engang deler et eneste ciffer. Et siger fire tusind, et siger fyrre, et siger lavmælt, at det kommer an på, og booker et andet møde. Ingen af dem lyver, sådan set — men ingen af dem fortæller dig det, du faktisk har brug for at vide, nemlig hvor pengene går hen, og hvorfor netop din app lander, hvor den lander. Så lad os åbne motorhjelmen.

Jeg har skrevet flere app-tilbud, end jeg kan tælle, for virksomheder lige fra en enmandshåndværker til en regional kæde. Den absolut mest almindelige reaktion på en pris er ikke chok over totalen — det er forvirring over spændet. Hvordan kan den samme tre-ords brief (”en bookingapp”) give estimater, der adskiller sig med en faktor ti? Det ærlige svar er, at ”en bookingapp” ikke er en brief. Det er et ønske. Prisen bor i de hundrede små beslutninger, der gemmer sig under den.

Denne tekst er den opdeling, jeg ville ønske, at enhver virksomhedsejer havde haft inden deres første opkald med en udvikler. Ingen fyld, ingen skræmmetaktik, intet mersalg. Bare de reelle omkostningsposter, de ting der lavmælt fordobler et budget, og et par ærlige måder at bruge mindre på uden at ende med noget, du fortryder.

Hvorfor to tilbud på ”den samme app” adskiller sig med 10x

Software er ikke et produkt, du tager ned fra en hylde — det er arbejde, målt i timer af dygtige mennesker. Så prisen på en skræddersyet app er grundlæggende bare omfang × timepris × risiko. Alt andet er en fodnote til de tre ting. Når to tilbud divergerer voldsomt, læses et af disse tre tal meget forskelligt, og som regel har ingen sagt det højt.

Omfang er det åbenlyse. ”En bookingapp” kan betyde en enkelt skærm, hvor kunder vælger et tidspunkt — eller det kan betyde personalekalendere, betalinger, påmindelser, kundelogin, et admin-dashboard, refunderinger og en rapport, ejeren læser om mandagen. Samme tre ord, ti gange arbejdet. Det billige tilbud antager ofte den lille version; det dyre antager lavmælt den store. Ingen af dem spurgte, hvilken du mente.

Så er der risikoen, den del ingen kan lide at prissætte. En vag brief, en kunde der ikke har besluttet, hvad den vil have, en integration med et knirkende gammelt system — disse tilføjer ikke bare timer, de tilføjer usikkerhed. Erfarne teams lægger en buffer på for usikkerhed, fordi de er blevet brændt af den. Et billigere tilbud har ofte slet ikke prissat risikoen, hvilket er præcis derfor, det nogle gange svulmer op halvvejs igennem.

Hvor pengene faktisk går hen

Når folk forestiller sig app-udvikling, forestiller de sig kodning. Kodning er virkelig, men det er sjældent engang halvdelen af regningen. En skræddersyet app er tættere på at bygge et lille hus end på at skrive et dokument — der er design, rørføring, syn og papirarbejde rundt om den synlige del. Sådan deles et typisk budget op, når du regner alt med.

To ting plejer at overraske folk i den tabel. For det første, hvor meget af budgettet der sker før en eneste linje funktionskode er skrevet — afklaring og design er ikke luksus, de er det billigste sted at rette en fejl. At ændre en skærm i en skitse koster minutter; at ændre den efter den er bygget koster dage. For det andet, hvor reel testlinjen er. At springe den over sparer ikke penge, den flytter bare omkostningen til din lanceringsuge, med renter.

Afklaring og design: den del alle vil springe over

Afklaring er der, hvor du forvandler ”en bookingapp” til en præcis liste over skærme og regler. Det føles som overhead, fordi der endnu ikke bygges noget. Men hver time her sparer flere længere fremme, fordi det er her, tvetydighed dræbes, mens den stadig er billig. Et team, der giver dig en pris uden en afklaringsfase, enten gætter eller planlægger at fakturere dig for afklaringen senere under et andet navn.

Kerneudvikling: den synlige motor

Dette er koden, der får din idé til at køre — skærmene folk trykker på, logikken bag dem, og databasen der lavmælt husker alt. Det er den største enkelte bid, og den skalerer næsten direkte med omfanget. Hver funktion du tilføjer er mere at bygge, mere at teste og mere at vedligeholde for evigt. Dette er linjen, hvor ”ville det ikke være rart hvis” hurtigt bliver dyrt.

Integrationer: den bedragerisk dyre del

At forbinde din app til andre systemer — modtage en kortbetaling, sende en SMS-påmindelse, synkronisere en kalender, hente data fra det regnskabsprogram du allerede bruger — ser småt ud på en funktionsliste og lander overraskende tungt på fakturaen. Hver forbindelse er et lille projekt i sig selv, med sine egne særheder og fejlmåder. Én velopdragen betalingsintegration er fin. Fem sammenfiltrede integrationer med et aldrende internt system er der, hvor budgetter går hen for at dø.

Omkostningerne ingen sætter i tilbuddet

Her får mange ejere en grim overraskelse tolv måneder inde. Bygget er et engangstal; en app er ikke en engangsting. Software er levende — telefoner opdateres, regler ændres, din virksomhed vokser — og en levende ting skal fodres. Tilbuddet du underskriver er prisen for fødslen, ikke prisen for ejerskabet.

Intet af dette er fup eller en skjult fælde — det er bare den del, der ikke passer pænt på et enkeltsides tilbud, så svagere partnere udelader den for at se billigere ud. En god fortæller dig om den på forhånd, selvom det får deres første tal til at se større ud. Spørg eksplicit: hvad koster det mig at drive dette i et år efter lancering? Kvaliteten af svaret fortæller meget om, hvem du har med at gøre.

Hvad der lavmælt fordobler prisen

Nogle ting tilføjer omkostning i forhold til den værdi, de bringer — fair nok. Andre tilføjer omkostning helt ude af proportioner, som regel på grund af hvordan arbejdet er struktureret snarere end hvad appen gør. Dette er håndtagene værd at forstå, fordi nogle af dem er fuldstændig inden for din kontrol.

• To platforme i stedet for en. En native iPhone-app og en native Android-app er, groft sagt, to byg. Cross-platform-værktøjer eller en webapp kan trække det tilbage mod ét. Dette ene valg kan flytte totalen mere end nogen funktion.
• Skræddersyet design frem for fornuftige standarder. En pixelperfekt, fuldt specialdesignet grænseflade koster rigtige penge at designe og bygge. En ren, konventionel der bruger gennemprøvede mønstre er hurtigere, billigere og ofte lettere for kunder at bruge.
• At ombestemme dig efter bygget er begyndt. Beslutninger er billige på en whiteboard og dyre i kode. Den mest almindelige budgetoverskridelse er ikke dårligt estimat — det er omfang, der blev ved med at vokse, fordi intet blev sømmet fast.
• Realtid, offline eller tunge data. ”Det skal virke uden signal” eller ”opdateringer skal vises øjeblikkeligt for alle” er rimelige ønsker, der lavmælt mangedobler ingeniørarbejdet nedenunder.
• At integrere med noget gammelt og udokumenteret. At forbinde til et moderne, velbygget system er rutine. At forbinde til et femten år gammelt internt værktøj uden dokumentation er arkæologi, og det faktureres pr. time.

Et virkeligt eksempel: tilbuddet på 60.000 € der blev en app til 14.000 €

Et par detaljer er ændret af hensyn til privatlivet, men formen på dette er sand og helt typisk. En regional servicevirksomhed — forestil dig et dusin medarbejdere i marken og et travlt kontor — kom til os frustrerede. De ville have en skræddersyet app, hvor deres kunder kunne booke opgaver, følge fremdrift og betale. De havde allerede fået et tilbud andetsteds på omkring 60.000 €, plus et solidt månedligt gebyr, og det havde skræmt dem fra hele idéen i den bedre del af et år.

Da vi faktisk kortlagde, hvad de havde brug for — ikke hvad de havde fået tilbud på — så billedet meget anderledes ud. Det første tilbud havde antaget to fuldt native apps, et specialdesign fra bunden, et realtidssystem til opgavefordeling og en skræddersyet admin-platform til at erstatte værktøjer, de allerede ejede og lavmælt var glade for. Det var, teknisk set, en udmærket app. Det var også et svar på et spørgsmål, de ikke havde stillet.

Hvad vi faktisk gjorde

Vi brugte de første sessioner på udelukkende afklaring — at skille ønsket ad i ”forretningen bryder sammen uden dette” over for ”det ville være rart en dag”. Skal-haves var smallere, end nogen havde forventet: en ren måde for kunder at anmode om og følge en opgave, automatiske påmindelser og onlinebetaling. Realtidsfordelingen og den skræddersyede backoffice viste sig at være løsninger på problemer, deres eksisterende software allerede klarede fint.

1. 1
   Skar omfanget ned til den reelle opgave

   Vi droppede de funktioner, der løste problemer, de ikke havde, og beholdt en stram liste, som forretningen oprigtigt ikke kunne køre uden.
2. 2
   Valgte ét cross-platform-byg

   I stedet for to separate native apps dækkede en enkelt cross-platform-app både iPhone og Android — hvilket cirka halverede kerneudviklingen.
3. 3
   Brugte gennemprøvede designmønstre

   En ren, konventionel grænseflade i stedet for en specialfremstillet. Kunderne fandt den lettere at bruge, og den barberede uger af tidsplanen.
4. 4
   Forbandt, erstattede ikke

   Vi koblede appen til den kontorsoftware, de allerede betalte for, i stedet for at genopbygge den. Den dyre ’skræddersyede admin-platform’ forsvandt simpelthen ud af omfanget.

Resultatet blev et byg på omkring 14.000 €, i drift på få måneder, med løbende omkostninger de kunne forudsige. Den er ikke så vidtfavnende som 60.000 €-versionen — og det behøver den ikke at være. Den gør den opgave, forretningen faktisk havde. Et år senere har de tilføjet to små funktioner ovenpå, betalt med de penge, den første version sparede dem. Det er hele mønsteret: start med den reelle opgave, fortjen ekstrafunktionerne med resultater.

Sådan holder du omkostningen fornuftig uden at gå på kompromis

At bruge mindre på en skræddersyet app handler ikke om at prutte timeprisen ned eller finde det billigste team, du kan. Sådan ender du med at betale dobbelt. Det handler om at være bevidst med omfang, rækkefølge og beslutninger — de tre ting der oprigtigt flytter tallet. Her bor de reelle besparelser.

For det første, byg den mindste version, der faktisk er nyttig, og lad den så vokse. En fokuseret første udgivelse, der gør én ting godt, får dig i drift hurtigere, koster en brøkdel af alt-i-én-drømmen og — afgørende — lærer dig, hvad du skal bygge næste gang fra rigtige kunder i stedet for gæt. For det andet, træf dine beslutninger inden bygget begynder; ubeslutsomhed er det dyreste, du kan bringe til et projekt. For det tredje, forbind til det du allerede ejer i stedet for at erstatte fungerende værktøjer, og genopbyg kun noget, når det oprigtigt holder dig tilbage.

Almindelige spørgsmål