8 dyra misstag i apputveckling som småföretag fortsätter göra

Här är den obekväma sanningen om appprojekt som spårar ur: när koden väl ser fel ut var projektet redan förlorat för veckor sedan. De dyra misstagen i apputveckling för småföretag sker nästan aldrig vid tangentbordet. De sker i förbigående samtal — uppdragsbeskrivningen som aldrig skrevs ner, funktionen som någon la till ‘när vi ändå håller på’, utvecklaren som valdes för att en vän rekommenderade dem. Inget av det känns som ett beslut i stunden. Allt kostar dig senare.

Jag har sett många småföretag beställa sin första app, och jag har blivit inkallad för att rädda gott om dem i efterhand. Ägarna är sällan slarviga människor. De är skarpa, noggranna, duktiga på att driva företag. Men mjukvara har sin egen uppsättning fällor som inte finns någon annanstans i deras arbetsliv, och ingen varnade dem. Så de går rakt in i samma åtta fallgropar, i ungefär samma ordning, varje gång.

Det här är listan jag önskar att varje ägare hade haft innan de spenderade ett öre. Inte teori — de faktiska, återkommande misstagen, och de små kursjusteringarna som hade räddat varje projekt. Om du står i begrepp att bygga en app, eller redan är mitt i bygget och något känns fel, läs det här först. De flesta av dessa går fortfarande att åtgärda om du upptäcker dem tidigt.

Misstag 1: Att bygga innan du bevisat att någon vill ha det

Det enskilt dyraste misstaget är också det vanligaste: att förbinda sig till ett fullständigt bygge innan det finns några verkliga bevis för att appen löser ett problem som folk vill betala för eller använda. Idén känns självklar för ägaren — såklart kommer kunder vilja ha det här — och just den vissheten är vad som är farligt. Visshet känns som validering. Det är det inte.

Validering betyder inte att fråga tio vänner om de gillar idén; alla säger ja för att vara snälla. Det betyder att sätta den minsta möjliga versionen framför riktiga användare i en riktig situation och titta på vad de faktiskt gör. En klickbar prototyp, en landningssida som mäter anmälningar, en manuell ‘concierge’-version där du fejkar automatiseringen för hand — vilken som helst av dessa säger dig mer än en färdig app byggd på en aning. Ordningen spelar roll: bevisa efterfrågan billigt, bygg sedan dyrt. Vänd på det och du kan spendera hela din budget på att putsa något som ingen öppnar en andra gång.

Misstag 2: Omfångsglidning utklädd till ambition

Varje app börjar slimmad och prydlig. Sedan börjar ‘när vi ändå håller på’. När vi ändå bygger bokningsskärmen, kan den inte också hantera presentkort? Och lojalitetspoäng? Och ett värvningssystem? Varje tillägg låter rimligt för sig. Tillsammans tredubblar de tyst tidslinjen och notan — och skjuter lanseringen så långt fram att den ursprungliga drivkraften dör.

Lösningen är inte att säga nej till bra idéer. Det är att parkera dem. Håll en synlig ‘version två’-lista där varje glänsande idé får vänta på sin tur. Det här gör något psykologiskt såväl som praktiskt: folk slutar slåss för att klämma in funktioner i den första releasen när de litar på att det finns en riktig plats för deras idé senare. Din första version ska göra en sak genuint bra, inte tio saker hjälpligt. En app som träffar mitt i prick på ett enda arbetsflöde blir använd. En app som gör allt halvdant blir övergiven.

Misstag 3: Ingen skriftlig uppdragsbeskrivning — bara en delad mental bild

Det här är osynligt tills det biter till. Ägaren har en tydlig app i huvudet. Utvecklaren har en tydlig app i huvudet. Alla nickar på uppstartsmötet. Ingen skriver ner det ordentligt — och de två bilderna, visar det sig, var aldrig samma bild. Du upptäcker det halvvägs in, när det som byggs inte är det du föreställde dig, och nu finns det ett gräl om vem som sa vad.

Du behöver ingen hundrasidig specifikation. Du behöver några sidor som vilken nykomling som helst kan läsa och förstå: vem använder den här appen, vilka är de tre eller fyra saker de behöver göra med den, hur ser ett lyckat resultat ut. Lägg till en grov skiss av nyckelskärmarna. Det är allt. Poängen med uppdragsbeskrivningen är inte byråkrati — det är en gemensam referens ni båda kan peka på när minne och verklighet börjar glida isär, vilket de alltid gör.

Misstag 4: Att välja utvecklaren på fel sätt

De flesta ägare väljer sin första utvecklare på en av två svaga signaler: lägsta offerten, eller en personlig rekommendation från någon i en helt annan bransch. Båda kan funka av tur. Ingendera är ett pålitligt sätt att välja någon du ska anförtro en betydande summa pengar och flera månader av ditt företags framtid.

Lägsta offerten är särskilt förrädisk i mjukvara, eftersom gapet mellan en offert och den färdiga kostnaden är enormt och osynligt. En billig utvecklare som behöver tre rundor av omarbetning, försvinner i två veckor och lämnar dig med kod som ingen annan kan underhålla är långt dyrare än en något dyrare som får det rätt. Pris är vad du ser; total kostnad är vad du betalar.

Vad du faktiskt ska kontrollera

Be att få se saker de levererat som fortfarande är i drift, och om du kan, prata med de kunderna utan utvecklaren i rummet. Fråga hur de hanterar ändringar mitt i projektet, för det kommer ändringar. Fråga vem som äger koden och kontona när det är klart — svaret ska alltid vara du. Och var uppmärksam på om de ställer bra frågor tillbaka. En utvecklare som bara tar emot order kommer bygga precis fel sak väldigt effektivt. De bra invänder, pekar på luckor i ditt tänkande och behandlar uppdragsbeskrivningen som en utgångspunkt för ett samtal, inte en fast inköpslista.

Misstag 5: Att budgetera för bygget och glömma resten

En app är inte ett engångsköp som en tryckt broschyr. Det är en levande sak som behöver matas. Ägare budgeterar rutinmässigt för bygget och inget annat, och blir sedan tagna på sängen av kostnaderna som kommer efteråt: hosting, app-store-avgifter, underhållet för att hänga med i telefonernas OS-uppdateringar, och den oundvikliga rundan av fixar och små förbättringar när riktiga människor börjar använda den.

En vettig tumregel: vad bygget än kostar, avsätt en betydande del av det igen för det första driftåret. Den exakta siffran varierar, men misstaget är universellt — att behandla lanseringsdagen som mållinjen när den faktiskt är startlinjen. Appen som lanseras och sedan tyst överges för att det inte finns någon budget att underhålla den är ett av de sorgligaste och vanligaste utfallen i hela det här fältet, och det går helt att undvika med ärlig planering i förväg.

Misstag 6: Att designa för dig själv istället för din användare

Du kan ditt företag utan och innan, vilket gör dig till den sämsta tänkbara domaren av om din app är lätt att använda. Saker som är självklara för dig — jargongen, ordningen du gör uppgifter i, genvägarna du tar utan att tänka — är förbryllande för en förstagångsanvändare. En app som är fullkomligt logisk för ägaren och förvirrar alla andra har misslyckats, hur smart den än är.

Botemedlet är billigt och en aning ödmjukande: titta på riktiga människor använda den innan du lanserar. Inte ditt team, som redan vet hur den är tänkt att fungera — riktiga kunder eller personal som aldrig sett den. Räck dem appen, ge dem en uppgift, och säg ingenting. Där de tvekar, trycker på fel sak eller suckar, där är din designfeedback. Fem personer räcker för att lyfta fram de värsta problemen. Att hoppa över det här steget är hur appar lanseras med en ‘skicka’-knapp som ingen kan hitta och ett registreringsflöde som tappar hälften av dem som försöker.

• Ge testaren en riktig uppgift, inte en rundtur — ‘boka en tid till nästa tisdag’, och var sedan tyst.
• Titta på deras händer och ansikte, inte bara om de till slut lyckas.
• Anteckna varje tvekan; en paus är ett designproblem du inte kan se inifrån.
• Motstå lusten att förklara — om du måste förklara det borde appen ha gjort det.
• Testa med fem personer, fixa de uppenbara misslyckandena, och testa sedan igen.

Misstag 7: Att bygga nativt iOS och Android när du inte behövde

Det finns en reflex att bygga en ‘riktig’ app för både iPhone och Android från dag ett, helt nativt, på det sätt de stora varumärkena gör. För de flesta småföretag är det två till tre gånger kostnaden och komplexiteten för en nytta dina användare aldrig kommer märka. Värre, du underhåller nu två separata kodbaser för evigt och dubblerar varje framtida fix.

Ofta är rätt första drag ingen nativ app alls. En välbyggd webbapp som fungerar i vilken telefons webbläsare som helst, eller ett plattformsoberoende angreppssätt som producerar båda app-store-versionerna från en kodbas, tar dig till marknaden snabbare och billigare — och du kan alltid gå helt nativt senare om verklig användning visar att det är värt det. Frågan att ställa är aldrig ‘nativt eller webb’ i det abstrakta. Den är: vad är den minsta, billigaste sak som låter riktiga användare göra kärnjobbet? Bygg det, lär av det, spendera sedan de stora pengarna med bevis istället för antagande.

Misstag 8: Att behandla lanseringen som slutet på arbetet

Det åttonde misstaget är att tro att projektet är klart när appen går live. Det är det inte — det är då det riktiga projektet börjar. En app utan plan för hur den ska nå användarnas händer, utan sätt att höra vad de tycker, och utan avsikt att förbättra den utifrån vad du lär dig är en app som bleknar bort inom månader. Bygget var den lätta delen. Att få den använd är den svåra delen, och nästan ingen planerar för det.

Innan du lanserar, känn till tre saker: hur folk ska få veta att appen finns, hur du mäter om de faktiskt använder den, och hur du samlar in det de berättar för dig så att nästa arbetsrunda styrs av verklighet istället för gissningar. Inget av det är dyrt. Det är bara ett annat tankesätt — appen är inte en sak du gör klar och går ifrån, det är en relation du underhåller. Ägarna som förstår det får appar som blir mer användbara med tiden. De som inte gör det får en topp på lanseringsdagen och en lång, tyst nedgång.

Hur du håller dig undan alla åtta på en gång

Lästa tillsammans delar dessa misstag en enda rot: att röra sig snabbt på antaganden istället för långsamt på bevis. Vart och ett av dem är ett ställe där det kändes billigare att hoppa över det noggranna steget. Och vart och ett av dem är långt billigare att hantera före bygget än efter. Här är sekvensen som tyst undviker alla åtta.

1. 1
   Bevisa efterfrågan innan du bygger

   En prototyp, en landningssida eller en manuell version. Skaffa verkliga bevis för att någon vill ha det här innan du binder budgeten.
2. 2
   Skriv uppdragsbeskrivningen och version två-listan

   Några tydliga sidor som vem som helst förstår, plus en parkeringsplats för varje ‘när vi ändå håller på’-idé så den inte spårar ur v1.
3. 3
   Välj utvecklaren på meritlista, inte pris

   Levererat arbete, referenssamtal, tydligt ägarskap av kod och konton, och någon som ställer bra frågor tillbaka.
4. 4
   Budgetera för hela första året, inte bara bygget

   Hosting, underhåll, fixar och support. Lanseringsdagen är startlinjen, så finansiera driften av saken.
5. 5
   Välj den minsta plattform som gör jobbet

   Webb eller plattformsoberoende först i de flesta fall. Gå helt nativt senare, med bevis, bara om användningen kräver det.
6. 6
   Testa med riktiga användare, planera sedan lanseringen

   Titta på fem främlingar använda den, fixa de uppenbara misslyckandena, och bestäm i förväg hur folk ska hitta den och hur du mäter användning.

Vanliga frågor