Spørsmålet er egentlig et regnestykke, og det er mer håndfast enn de fleste tror.
En app lønner seg når den fjerner nok tid, feil eller tapte inntekter til å dekke både utviklingen og driften over noen år. Alt annet er antakelser. Så før vi snakker om teknologi, la oss se på hvordan du faktisk regner på det.
Regnestykket
Ta en oppgave folk gjør i dag og som appen skal gjøre enklere. Finn ut hvor lang tid den tar, hvor mange som gjør den, og hvor ofte.
Bruker femten montører tjue minutter hver dag på å føre timer og rapportere på papir som noen andre etterpå må punche inn, snakker vi om fem timer daglig på tvers av organisasjonen. Over et år blir det godt over tusen timer. Selv om appen bare halverer tidsbruken, er gevinsten stor nok til å bære et prosjekt til flere hundre tusen.
Bruker tre personer ti minutter i uka på det samme, er svaret nei. Da er en app en dyr måte å spare noen timer i året.
Dette er grunnen til at interne apper ofte lønner seg raskere enn kundevendte apper. Gevinsten er målbar, brukerne er kjente, og dere trenger ikke overbevise noen om å laste den ned.
Situasjonene der det som regel stemmer
Det finnes noen mønstre som går igjen hos bedriftene som får mest ut av en app.
Den tydeligste er arbeid som skjer utenfor kontoret. Folk som er ute hos kunder, på anlegg, i butikk eller på veien, har i dag ofte en løsning som innebærer papir, telefonsamtaler eller å vente til de er tilbake ved en PC. En app som lar dem registrere noe der og da, gjerne uten nett, fjerner et helt ledd. Dette er den klareste gevinsten vi ser.
Den nest tydeligste er dobbeltarbeid. Data skrives inn ett sted, sendes videre på e-post, og skrives inn på nytt i et annet system. Hvert ledd koster tid og introduserer feil. En løsning som fanger dataene én gang og sender dem dit de skal, betaler seg fort.
Den tredje er ventetid som koster penger. Hvis en godkjenning tar tre dager fordi noen må være på kontoret for å gi den, og prosjektet står stille imens, er det en kostnad som sjelden står i noe regneark, men som er reell.
For kundevendte apper er mønsteret annerledes. Der lønner det seg når kunden bruker tjenesten jevnlig, og appen enten gjør det enklere å kjøpe mer eller reduserer henvendelser til kundeservice.
Når du bør la være
En app er feil svar når bruken er sjelden. Noe kunder trenger to ganger i året, kommer de aldri til å installere. Da er en nettside eller webapplikasjon riktig, og vi har gått gjennom den avveiningen i app eller nettside.
Den er også feil svar når problemet er en prosess, ikke et verktøy. Hvis rapporteringen er tungvint fordi ingen har bestemt hvem som skal gjøre hva, løser ikke en app det. Da får dere den samme uklarheten, bare digitalisert og dyrere.
Og den er feil svar når systemet dere allerede har kan gjøre jobben. Mange fagsystemer har funksjonalitet som aldri er tatt i bruk, eller en mobilløsning ingen har satt opp. Det er verdt en telefon til leverandøren før dere bygger noe nytt.
Kostnaden du må ha med i regnestykket
Utviklingen er engangskostnaden, og den er den synlige. En enkel app for både iOS og Android, uten innlogging, ligger på 50 000 til 100 000 kroner med skreddersydd design inkludert. Trenger den innlogging og en backend, er nivået 80 000 til 300 000 avhengig av hvor mye funksjonalitet som skal med. Du kan sette sammen et anslag i priskalkulatoren.
Deretter kommer det løpende. Regn 10 til 20 prosent av utviklingskostnaden i årlig vedlikehold, fordi Apple og Google endrer plattformene sine hvert år og krever at apper bygges mot nyere versjoner for å bli værende i butikkene. Legg til drift av servere og database.
Og legg til det ingen setter i budsjettet: tiden deres egne folk bruker. Avklaringer, testing, opplæring og oppfølging. Et appprosjekt krever noen hos dere som eier det, og den personen bruker reell arbeidstid.
Start mindre enn du tror
Den vanligste måten å tape penger på et appprosjekt er å bygge alt på en gang. Det tar lengre tid, koster mer, og dere finner ut om det traff først når alt er brukt opp.
Bygg i stedet den ene arbeidsflyten som koster mest tid i dag, sett den i drift hos en liten gruppe, og mål om det faktisk ble raskere. Fungerer det, har dere både et grunnlag for å utvide og et tall å vise til internt. Fungerer det ikke, har dere spart resten av budsjettet. Vi har skrevet mer om denne tilnærmingen i MVP-apputvikling.
Slik vurderer du det selv
Still tre spørsmål før dere går videre.
Hvilken konkret oppgave skal appen gjøre raskere, og hvor mye tid går med til den i dag? Kan dere ikke svare med et tall, er dere ikke klare til å bestille.
Hvem skal bruke den, og hvor ofte? Daglig bruk av en kjent gruppe er det beste utgangspunktet.
Og hva skjer hvis dere ikke gjør noe? Hvis svaret er at det går helt greit, er det kanskje riktig svar for i år.
Vil du ha hjelp til å gå gjennom regnestykket? Se hvordan vi jobber med apputvikling, eller ta kontakt. Vi sier fra hvis vi mener tallene ikke bærer prosjektet.