Å lage en app er en større beslutning enn de fleste tror når de begynner, og en mindre skummel enn de tror når de er halvveis. Det som skiller prosjekter som går bra fra de som ikke gjør det, er som regel avgjort før noen har skrevet en linje kode.
Her er det du bør ta stilling til, i den rekkefølgen det gir mening.
Definer hva appen faktisk skal løse
Begynn med å beskrive problemet uten å nevne ordet app.
Hvis kundene ringer utenom åpningstid for å bestille, så er det problemet. En app er én mulig løsning. En bookingside er en annen, og den er billigere. Ved å beskrive problemet først, holder du muligheten åpen for at det finnes en enklere vei.
Still tre spørsmål og krev konkrete svar. Hva gjør folk i dag for å løse dette? Hvorfor er det ikke godt nok? Og hva koster det dem i tid eller penger? Klarer du ikke å svare med et tall på det siste, er det et tegn på at behovet ikke er modent ennå.
Undersøk hva som allerede finnes
Søk i App Store og Google Play etter det du vil lage. Finner du noe som ligner, er det ikke nødvendigvis dårlig nytt. Det betyr at noen har bekreftet at behovet finnes.
Det interessante ligger i anmeldelsene, særlig de på to og tre stjerner. Der står det hva folk savner og hva som irriterer dem. Det er den billigste markedsundersøkelsen du får, og den forteller deg ofte hva din versjon bør gjøre annerledes.
Finner du derimot ingenting, er det verdt å tenke gjennom hvorfor. Noen ganger er det fordi ingen har tenkt på det. Oftere er det fordi noen har prøvd og funnet ut at folk ikke vil ha det.
Velg plattform etter hvor brukerne er
Spørsmålet om iOS, Android eller begge er mindre dramatisk enn det pleide å være, fordi de fleste apper i dag bygges med felles kodebase og dekker begge.
Er budsjettet stramt, kan du lansere på én plattform først. I Norge har iPhone en sterk posisjon, særlig blant privatkunder, mens Android er vanligere i enkelte yrkesgrupper. Skal appen brukes av egne ansatte, vet dere allerede hvilke telefoner de har, og da er svaret gitt.
Ta stilling til teknologi, men ikke la den styre
Det finnes tre hovedveier, og valget påvirker både pris og hva appen kan.
Native betyr to separate apper, én for hver plattform, med best mulig ytelse og full tilgang til alt telefonen kan. Det koster mer å bygge og vesentlig mer å vedlikeholde, siden alt gjøres to ganger.
Kryssplattform betyr én kodebase for begge. For de aller fleste forretningsapper er dette riktig valg, fordi brukerne ikke merker forskjell mens budsjettet gjør det.
Webapp er ikke en app i det hele tatt, men en nettside bygget for å oppleves som en. Den slipper app-butikkene og kan oppdateres når som helst, men har begrenset tilgang til maskinvare og upålitelige varsler.
Vi har gått grundig gjennom avveiningen i native, hybrid eller webapp.
Design handler om at folk får gjort jobben
Det vanligste misforståelsen er at design er hvordan appen ser ut. Det viktigste er hvor mange trykk som kreves for å fullføre den vanligste oppgaven, og om folk forstår hva de skal gjøre uten å bli forklart det.
Den billigste måten å sikre dette på er å lage en klikkbar prototype og vise den til fem personer fra målgruppen. Gi dem en oppgave, si ingenting, og se hvor de nøler. Tjue minutter per person avdekker mer enn tre interne møter.
Det som kommer fram er sjelden at konseptet er feil. Det er at en knapp heter noe folk ikke leter etter, eller at to steg står i motsatt rekkefølge av hvordan folk faktisk jobber.
Egne folk eller ekstern leverandør
Skal appen være kjernen i forretningsmodellen deres, og skal den leve i mange år, er det gode argumenter for å bygge kompetansen internt. Kontinuitet er vanskelig å kjøpe.
Skal den løse et avgrenset behov, eller er dette første gang dere gjør noe slikt, er en ekstern leverandør som regel både raskere og rimeligere. Dere slipper rekrutteringsløpet, som typisk tar fire til seks måneder, og dere betaler for arbeid framfor for en fast stilling.
En vanlig mellomvei er å leie inn mens dere rekrutterer. Mer om det i hvorfor leie en konsulent.
Budsjett, inkludert det som kommer etterpå
En enkel app for begge plattformer, uten innlogging, ligger på 50 000 til 100 000 med skreddersydd design inkludert. Deretter koster hver funksjon sitt: innlogging 25 000 til 50 000, betaling 30 000 til 60 000, et administrasjonspanel 70 000 til 130 000. En app med innlogging og backend havner dermed typisk på 80 000 til 300 000, og en med web-panel på 200 000 til 500 000 og oppover.
Den posten folk glemmer er vedlikehold. Apple og Google gir ut nye versjoner av operativsystemene hvert år og krever jevnlig at apper bygges mot nyere versjoner for å bli værende i butikkene. Regn 10 til 20 prosent av utviklingskostnaden årlig, pluss drift av servere.
Du kan sette sammen et anslag i priskalkulatoren, og lese mer i hva koster det å lage en app i Norge.
De juridiske tingene som må avklares tidlig
Behandler appen personopplysninger, gjelder personvernforordningen. Bestem tidlig hvilke data dere faktisk trenger, framfor å samle inn alt som er lett tilgjengelig. Dere trenger også en personvernerklæring, og begge app-butikkene krever at dere oppgir hvilke data appen samler inn.
Avklar hvem som eier koden. Svaret bør være dere, og det bør stå i avtalen. Det er ikke en selvfølge i bransjen.
Er appen rettet mot allmennheten, kommer krav til universell utforming i tillegg. Mer om det i skap en inkluderende nettside.
Testing er ikke en fase på slutten
Prosjekter som utsetter all testing til slutten, får en hale av feilretting ingen kan estimere. God praksis er å teste underveis, både automatisk og ved at dere selv prøver appen på ekte telefoner.
Be om testversjoner minst annenhver uke. Det er først når du klikker på noe at du oppdager om det ble som du tenkte.
Lansering og det å bli funnet
Appen skal inn i begge butikkene. Apple gjennomgår hver innsending manuelt, og de vanligste grunnene til avvisning er mangelfull informasjon om datainnsamling og funksjonalitet som ikke lar seg teste uten demokonto.
Tenk også gjennom hvordan folk skal finne appen. Innhold inne i en app finnes ikke i søk, så en nettside som forklarer hva appen gjør er som regel det rimeligste og viktigste tiltaket.
Planlegg for tiden etter lansering
Lansering er ikke målstreken. Det er første gang dere får vite hva brukerne faktisk gjør, framfor hva dere trodde de ville gjøre.
Hold av en del av budsjettet til de første månedene etterpå, og bestem på forhånd hvordan dere måler om appen brukes. Ett tall dere følger med på er mer verdt enn en rapport ingen åpner.
Kort oppsummert
Start mindre enn du vil. Test med ekte brukere før du bygger. Sett av penger til det som kommer etter lansering. Og sørg for at én person hos dere kan ta beslutninger raskt.
Har du et problem du kan beskrive konkret, er du klar til å ta en prat. Ta kontakt, så sier vi ærlig fra om vi mener en app er riktig svar.