For en startup er den viktigste beregningen ikke hva appen koster, men hvor lenge pengene varer. Hver måned med utvikling er en måned uten inntekt og uten svar på det spørsmålet som faktisk avgjør alt: vil noen bruke dette?
Derfor handler god apputvikling for startups mindre om å bygge fort, og mer om å bygge lite. Og om å tenke på hvordan folk skal finne produktet lenge før det er ferdig.
Finn den ene tingen
De fleste startups vi snakker med har en visjon som krever tjue funksjoner. Den visjonen kan godt være riktig, men den er ikke det du skal bygge først.
Spørsmålet er hvilken enkelt ting som gjør at den aller første brukeren får verdi. Ikke hva som gjør produktet komplett, men hva som gjør at én person sier at dette var nyttig. Alt annet er versjon to.
Dette er vanskeligere enn det høres ut, fordi hver funksjon føles nødvendig når du har tenkt på den lenge. En nyttig test: hvis du måtte lansere om seks uker, hva ville du bygget? Det svaret er som regel nærmere sannheten enn den opprinnelige lista. Vi har skrevet mer om avgrensningen i MVP-apputvikling.
Test premisset før du bygger
Det billigste produktet er det du slipper å lage.
Før noen skriver kode, lag en klikkbar prototype og vis den til folk i målgruppen. Ikke venner og familie, som vil være hyggelige, men folk som faktisk har problemet. Gi dem en oppgave og la dem prøve uten hjelp.
Det du leter etter er ikke om de synes ideen er god. Alle synes ideer er gode. Du leter etter om de forstår hva de skal gjøre, og om de sier noe som antyder at de har dette problemet i dag. Spør hva de gjør nå for å løse det. Hvis svaret er ingenting, er problemet kanskje ikke stort nok.
Bygg det som er ditt, kjøp resten
Innlogging, betaling, varsler og filhåndtering er løste problemer. Bruk etablerte tjenester for dem. Ingen investor eller kunde bryr seg om at dere har bygget deres eget påloggingssystem, og det er uker med arbeid som ikke gjør produktet bedre.
Det dere skal bygge er det som er særegent for produktet. Alt annet er infrastruktur, og infrastruktur kjøper man.
Det samme gjelder administrasjonspanel. Med de første brukerne kan dere håndtere ting manuelt. Det er ikke elegant, men et web-panel er ofte det som løfter et prosjekt opp i et helt annet prissjikt, og de pengene gjør mer nytte når dere vet at produktet virker.
Velg teknologi dere kan leve med
Kryssplattform gir dere begge mobilplattformer fra én kodebase, og det er som regel riktig for en startup fordi dere ikke vet hvor brukerne er ennå.
Vurder også om dere trenger en app i det hele tatt i første runde. En webapplikasjon kan testes uten app-butikker, uten godkjenningsprosess, og kan endres samme dag. For mange produkter er det raskeste vei til de første brukerne. Vi har gått gjennom avveiningen i app eller nettside.
Hva det koster og hvor lang tid det tar
Prisen avgjøres først og fremst av om appen trenger brukerkontoer. En enkel første versjon som lagrer data lokalt på telefonen, uten innlogging, ligger på 50 000 til 100 000 kroner og kan være ute på tre til fem uker. Trenger den innlogging og en backend, som de fleste produkter med delte data gjør, er nivået 80 000 til 300 000 kroner og seks til fjorten uker, avhengig av hvor mye som skal med.
Det er ikke nok til å bygge visjonen. Det er nok til å finne ut om visjonen er verdt å bygge, og det er riktig bruk av de første pengene. Du kan regne på ditt eget omfang i priskalkulatoren, og prisnivåene er forklart nærmere i hva koster det å lage en app.
Undersøk også støtteordninger tidlig. SkatteFUNN kan gi skattefradrag for prosjekter med reelt utviklingsinnhold, og Innovasjon Norge har ordninger for oppstartsbedrifter. Flere av dem forutsetter at du søker før arbeidet settes i gang, så sjekk gjeldende vilkår mens prosjektet fortsatt er på planleggingsstadiet.
Begynn på lanseringen før produktet er ferdig
Det finnes en fase i oppstartsprosjekter som nesten ingen planlegger for: uka etter lansering, når produktet er ferdig og ingen vet at det finnes. En app ingen laster ned, er verdt like mye som ingen app. Dette er ikke utviklerens ansvar, og det er derfor det ofte ikke blir noen sitt ansvar.
Det som virker er å samle interesse mens dere bygger. En enkel landingsside som forklarer hva produktet løser og lar folk melde seg på, koster lite og kan stå ute fra måned én. Den kan i tillegg rangere i søk, noe innhold inne i en app aldri kan.
Den gir dere to ting. En liste med folk å kontakte den dagen dere lanserer, og et tidlig signal om hvorvidt noen i det hele tatt er interessert. Får dere ikke noen påmeldinger på en side som beskriver produktet, er det verdifull informasjon å ha før dere bygger ferdig.
De første brukerne finner dere manuelt
Dette er den delen folk ikke liker å høre. De første tjue brukerne skaffes ikke gjennom markedsføring, de skaffes ved at dere kontakter folk én og én.
Det er arbeid som ikke skalerer, og det er nettopp derfor det er verdt å gjøre. Hver samtale gir dere innsikt dere ikke får av et tall i et dashbord. Dere hører hvilke ord folk bruker, hva de misforstår, og hva som får dem til å nøle.
Snakk med de samme folkene dere testet prototypen på. De kjenner produktet, de har allerede investert litt oppmerksomhet, og de er som regel villige.
App Store er ikke en distribusjonskanal
Mange planlegger som om det å ligge i butikken er nok. For de aller fleste apper er det ikke det.
Folk finner sjelden en ny app ved å søke i App Store, med mindre de allerede vet hva de leter etter. De finner den fordi noen anbefalte den, fordi de leste om den, eller fordi de kom via nettet.
Det betyr at innsatsen bør ligge utenfor butikken. Butikkoppføringen skal være ryddig, med skjermbilder som viser hva appen gjør framfor et pent oppstartsbilde, men den er siste ledd i kjeden, ikke første. Mer om hvorfor nettsiden bærer så mye av jobben i hvor viktig er SEO når du lager en app.
Planlegg for godkjenningsprosessen
Apple gjennomgår hver innsending manuelt. Det går ofte raskt, men en avvisning kan koste dager, og de kommer alltid på verst tenkelig tidspunkt.
De to vanligste grunnene er mangelfull informasjon om hvilke data appen samler inn, og at Apple ikke får testet funksjonalitet som ligger bak innlogging. Send med en demokonto, og fyll ut personvernopplysningene ordentlig. Sett aldri en lanseringsdato som forutsetter at første innsending går gjennom.
Mål én ting fra dag én
Bestem før lansering hva som forteller dere om produktet fungerer. Hvor mange som fullfører hovedoppgaven første gang. Hvor mange som kommer tilbake uka etter.
Ett tall dere følger med på er mer verdt enn en full analyseløsning ingen ser på. Det gir dere også noe konkret å vise investorer og noe å diskutere internt når dere skal bestemme hva som bygges videre.
Hold av penger til etter lansering
Dette er den vanligste og dyreste feilen vi ser hos oppstartsselskaper. Hele budsjettet går til versjon én, og så er det ingenting igjen når brukerne begynner å fortelle hva som mangler.
Det er nettopp da pengene gir mest. Månedene etter lansering er når dere endelig bygger på noe dere vet framfor noe dere tror. Hold av minst en fjerdedel av rammen til denne fasen.
Hva investorer faktisk vil se
En klikkbar prototype er ofte nok i tidlig fase, og langt rimeligere enn en ferdig app. Den viser at dere har tenkt gjennom produktet, og den lar dere teste med brukere før dere har brukt penger på å bygge.
Har dere i tillegg noen tall fra ekte bruk, om det så bare er tjue personer, er det mer overbevisende enn en komplett app ingen har prøvd. Vi har skrevet mer om dette i hvordan prototype app hjelper med å tiltrekke investorer.
Vær forberedt på at svaret kan bli nei
Noen ganger viser de første brukerne at premisset ikke holdt. Det er ikke et nederlag, det er det dere kjøpte for pengene: å finne det ut etter tre måneder framfor etter to år.
Prosjekter som ikke tør å ta den beslutningen, bruker gjerne like mye igjen på å bevise at den første antakelsen var riktig.
Kom i gang
Beskriv problemet, hvem som har det, og hva de gjør i dag. Har du det klart, kan vi gi deg en vurdering av hva som er mulig innenfor rammen din.
Se hvordan vi jobber med apputvikling, eller ta kontakt. Vi sier fra hvis vi mener dere bør teste mer før dere bygger.