Har I virkelig brug for en app, eller er en webapp nok?

Af Weapp · Opdateret

En app giver mening når brugerne ofte vender tilbage og har brug for push-notifikationer, offlinetilstand eller telefonens hardware. Er det nok at være en søgning væk, vinder nettet: større rækkevidde, én kodebase og ingen godkendelse i app-butikkerne. Mange teams starter derfor med en webløsning og bygger først en app når tilbagevendende brug er dokumenteret.

“Vi har brug for en app” er ofte det forkerte udgangspunkt. Det rigtige spørgsmål er: Hvor ofte kommer brugerne tilbage, og hvad skal de kunne gøre når de gør det? Svaret afgør om I skal investere i en app der skal downloades, eller starte på nettet. Her er beslutningsgrundlaget, ud fra brugsmønstre og ikke prestige.

Hvornår en app giver mening

En app på hjemmeskærmen fortjener sin plads når mindst et par af disse kriterier er opfyldt:

  • Hyppig brug. Brugeren vender tilbage flere gange om ugen. Så betaler downloadet sig, og ikonet på hjemmeskærmen bliver en påmindelse i sig selv.
  • Notifikationer. Push er appens stærkeste værktøj til at skabe tilbagevendende adfærd: bookingpåmindelser, leveringsbeskeder, “din tur i køen”.
  • Offline. Appen skal virke uden netforbindelse: ude i felten, i en kælder, på rejse.
  • Hardware. Kamera i realtid, Bluetooth, NFC, sensorer eller lokationstjenester i baggrunden kræver i praksis en rigtig app.

Passer intet af dette, er appen sandsynligvis en dyr omvej. En download er en tærskel, og en app der bruges en gang i kvartalet, bliver afinstalleret eller glemt.

Nettets fordele er lette at undervurdere

Nettet har tre strukturelle fordele der ofte vejer tungere end de ser ud til på et strategimøde:

  • Rækkevidde. En webløsning er et link. Den kan deles i en sms, sendes på mail, annonceres og findes via Google uden at brugeren skal installere noget.
  • Én kodebase. Den samme løsning virker på mobil, tablet og computer. Det sænker både udviklings- og vedligeholdelsesomkostningerne sammenlignet med separate apps.
  • Ingen godkendelse i app-butikkerne. I udgiver forbedringer når I vil, på minutter i stedet for dage. Apple og Google har ingen vetoret over jeres release.

Dertil kommer tærsklen for brugeren: At klikke på et link tager sekunder, at downloade en app kræver en beslutning. For tjenester der bruges sjældent eller af et bredt publikum der kun kommer forbi lejlighedsvis, er den forskel ofte afgørende for hvor mange der faktisk kommer ind.

Et konkret scenarie

Forestil jer et padelcenter der vil digitalisere bookingen. Første mulighed: at bygge en app med det samme for anslået 530.000–850.000 DKK. Anden mulighed: at starte med en webbaseret booking der fungerer lige så godt fra en Google-søgning som fra et link i en sms, til en lavere pris.

Efter en sæson med webløsningen har I det sort på hvidt: hvor stor en andel der booker hver uge, hvor mange der vil have påmindelser, hvor ofte der frigives afbestilte tider som stamkunderne gerne vil snuppe. Viser dataene en hyppig, tilbagevendende adfærd, giver appen mening, nu med push-notifikationer om ledige tider som tydelig kerneværdi og med hele bookinglogikken allerede bygget og betalt. Viser dataene det ikke, har I sparet flere hundrede tusinde DKK.

Den typiske rækkefølge: web først, app når adfærden er dokumenteret

Den mest almindelige fejl er ikke at vælge den forkerte kanal, men at vælge begge for tidligt. En gennemprøvet rækkefølge ser sådan ud:

  1. Byg webløsningen omkring kerneflowet, og gør den fremragende på mobilen.
  2. Mål adfærden: tilbagevendende brug, mobilandel, efterspørgsel efter notifikationer.
  3. Byg appen når dataene viser at den løser et reelt behov, med backend, design og forretningslogik genbrugt fra webløsningen.

Rækkefølgen mindsker også den organisatoriske risiko. En app forpligter: Den skal vedligeholdes, opdateres i takt med nye versioner af iOS og Android og retfærdiggøre sin plads på brugerens hjemmeskærm. At udskyde den investering indtil efterspørgslen er dokumenteret, er ikke forsigtighed, men god husholdning med produktbudgettet.

Rækkefølgen har en vigtig undtagelse: når appen er selve produktet. Træningstracking med sensorer, værktøjer der skal virke offline i felten eller tjenester hvor notifikationen er kerneværdien: Dér findes der ingen meningsfuld webversion at validere med, og så er det rigtigt at gå direkte til en app.

Sådan træffer I beslutningen

Tre spørgsmål rækker langt: Hvor ofte vender en typisk bruger tilbage? Hvilken funktion er kerneværdien, og kræver den app-teknologi? Hvad siger jeres data i dag hvis I allerede har en digital tjeneste?

Er svaret stadig uklart, er en kort forundersøgelse som regel den billigste vej til en tryg beslutning. Vi hos Weapp hjælper jævnligt teams med at afklare netop det spørgsmål før der skrives kode. Læs mere om vores ydelser, eller kontakt os, så drøfter vi det helt åbent.

Ofte stillede spørgsmål

Hvad er forskellen på en webapp og en native app?

En webapp kører i browseren og åbnes via et link. En native app installeres fra App Store eller Google Play. Den native app har fuld adgang til push-notifikationer, offlinetilstand og telefonens hardware. Webappen når til gengæld flere brugere med mindre friktion og kan opdateres når som helst.

Kan man bygge appen senere uden at starte forfra?

Ja, hvis webløsningen bygges med det for øje. Med en API-first-tilgang genbruges hele backenden når appen bygges, og vælger I React på nettet, deler et fremtidigt React Native-projekt både kompetencer og kodemønstre. Det der bygges nyt, er i praksis brugerfladen.

Hvordan ved vi om brugerne vil have en app?

Se på adfærden i webløsningen. Vender de samme brugere tilbage flere gange om ugen, bruges tjenesten mest på mobilen, eller efterspørges der notifikationer, så er der grundlag for en app. Gæt før lanceringen er et markant svagere grundlag end faktiske brugsdata.

Hvad koster en app sammenlignet med en webapp?

En enklere mobilapp koster oftest 320.000–850.000 DKK. En webapp med tilsvarende funktioner lander ofte lavere fordi den slipper for distribution via app-butikkerne og tilpasning til hver platform. Den store forskel er løbende: Appen kræver opdateringer i takt med hver ny version af iOS og Android.

Er en PWA en mellemting?

Ja. En progressiv webapp kan lægges på hjemmeskærmen, sende push-notifikationer med visse begrænsninger og delvis virke offline, helt uden app-butikker. For mange organisationer er PWA’en et godt andet skridt før der bygges en fuld native app.