Mye av det som skrives om appplanlegging er generelt og kunne vært skrevet hvor som helst i verden. Men et appprosjekt i Norge har noen forutsetninger som endrer både budsjett og tidsplan, og som er verdt å ta stilling til før utviklingen starter.
Markedet er lite, forventningene til innlogging og betaling er spesifikke, personvernreglene håndheves, og det finnes støtteordninger som kan dekke deler av kostnaden hvis du søker i tide. Her er det vi pleier å ta opp med norske kunder i planleggingsfasen.
Et lite marked endrer regnestykket
Norge har rundt 5,5 millioner innbyggere. Selv en app som treffer bredt, snakker om et begrenset antall brukere sammenlignet med hva de internasjonale eksemplene bygger på.
Det har to praktiske konsekvenser. For det første må inntektsmodellen tåle små tall. En app som trenger hundretusener av brukere for å gå rundt på annonser, er sjelden realistisk her. Abonnement, betaling per bruk eller salg til bedrifter fungerer bedre, fordi verdien per bruker er høyere.
For det andre betyr det at du sjelden har nok data til de mest avanserte funksjonene. Anbefalingsmotorer og maskinlæring som tilpasser seg hver enkelt bruker, trenger volum for å bli bedre enn et gjennomtenkt standardoppsett. Med noen tusen brukere er det som regel bortkastede penger.
Til gjengjeld er et lite marked oversiktlig. Du kan faktisk snakke med en meningsfull andel av målgruppen din før du bygger, og det er den billigste researchen som finnes.
Innlogging og betaling folk forventer
Norske brukere har vaner som er verdt å ta på alvor.
Skal appen identifisere hvem folk er med sikkerhet, forventer mange BankID. Det er en integrasjon som krever avtale med en leverandør, har en løpende kostnad per bruk, og som tar tid å få på plass. Start den prosessen tidlig, for den går ikke fortere av at utviklingen er ferdig.
Skal folk betale, er Vipps nesten alltid forventet. Kortbetaling alene oppleves som tungvint av mange, særlig på mobil. Vipps krever også avtale og godkjenning, og det er verdt å regne inn i tidsplanen.
Begge deler er eksempler på noe som ser ut som en liten linje i kravspesifikasjonen, men som kan bli det som avgjør når dere faktisk kan lansere. Vi tar dette opp i første møte nettopp fordi ventetiden ligger utenfor vår kontroll.
Personvern er ikke noe du rydder opp i etterpå
Behandler appen personopplysninger, gjelder personvernforordningen, og Datatilsynet håndhever den.
Det viktigste er å bestemme tidlig hvilke data dere faktisk trenger. Den vanligste feilen er å samle inn alt som er lett tilgjengelig, fordi det kan bli nyttig senere. Det gir dere en forpliktelse dere må leve med, uten tilsvarende verdi.
Ta også stilling til hvor dataene lagres. Bruker dere en skytjeneste, bør dere vite hvilken region den kjører i og hva avtalen sier om overføring ut av EØS. Det samme gjelder hvis appen sender data til en ekstern AI-tjeneste. Dette er raskt å avklare i planleggingen og tungt å rette i ettertid.
Skal løsningen brukes av det offentlige, kommer universell utforming i tillegg som et absolutt krav. Da er WCAG på nivå AA minstekravet, og en løsning som ikke oppfyller det blir avvist uansett hvor god den ellers er. Vi har skrevet mer om det i skap en inkluderende nettside.
Støtteordninger du må søke på før du starter
Dette er den delen flest går glipp av, og det er nesten alltid fordi de fant ut av det for sent.
SkatteFUNN gir skattefradrag for prosjekter med reelt utviklingsinnhold, altså der dere løser noe som ikke har en kjent løsning fra før. En app som setter sammen kjent teknologi på vanlig måte kvalifiserer sjelden, mens et prosjekt som utvikler noe nytt ofte gjør det. Innovasjon Norge har egne ordninger rettet mot oppstartsbedrifter.
Det viktige er tidspunktet. Flere ordninger forutsetter at du søker før arbeidet settes i gang, og vilkårene justeres fra år til år. Sjekk gjeldende regler direkte hos dem, og gjør det mens prosjektet fortsatt er på planleggingsstadiet.
Hva som bør være med i første versjon
Når rammene er på plass, står det egentlige spørsmålet igjen: hva skal bygges først?
Den nyttigste øvelsen er å beskrive én bruker som får én oppgave gjort, fra start til slutt. Alt som trengs for at den reisen skal fungere, er med i første versjon. Alt annet venter. Dette er hele poenget med en MVP, og vi har utdypet tankegangen i MVP-apputvikling.
I praksis betyr det at administrasjonsgrensesnitt, statistikk, flere brukerroller og integrasjoner mot interne systemer ofte kan vente. Det føles feil å utsette, men det er forskjellen på å være i markedet om fire måneder og om fjorten.
En klikkbar prototype er det beste verktøyet for å ta den beslutningen, fordi den gjør diskusjonen konkret. Det er lettere å bli enige om hva som kan vente når alle ser det samme skjermbildet.
Å velge partner
Norske utviklingstimer koster mer enn i mange andre land, og det er en reell vurdering å gjøre. Det som ofte veier opp, er nærhet til markedet og at kommunikasjonen går uten friksjon. Misforståelser er dyre, og de oppstår lettest når avstanden er stor, både geografisk og språklig.
Spør uansett hvem du snakker med om tre ting. Hvem eier koden når prosjektet er over? Hvor ofte får du se noe som faktisk virker? Og hva koster det å drifte og vedlikeholde løsningen i året etter lansering?
Vi svarer gjerne på alle tre. Se hvordan vi jobber med apputvikling, få et grovt estimat i priskalkulatoren, eller ta kontakt for en uforpliktende prat om prosjektet ditt.