Skal Din Restaurant Have Sin Egen App? De 4 Tal, Der Afgør Det

I denne artikel

1. 1. Hvad det koster at bygge en app — og at blive ved med at betale for den
2. 2. Hvor mange af dine gæster der reelt installerer den
3. 3. Hvem der stadig åbner appen efter 30 og 90 dage
4. 4. Hvor mange ekstra besøg der skal til for at hvile i sig selv
5. Når regnestykket rent faktisk går op
6. Hvad du gør, før du skriver under

Et lokalt webbureau, din kasseleverandør eller en franchisekonsulent stiller før eller siden det samme spørgsmål: vil du have din egen app? Svaret, du får, er næsten altid følelsesladet — "vær der, hvor din gæst er" — og næsten aldrig regnet igennem på papir. Denne artikel regner det igennem, med de tal appindustrien selv offentliggør.

En native app lyder som det logiske næste skridt efter din hjemmeside: din gæst bestiller allerede fra en skærm, så hvorfor ikke også fra et ikon på telefonen? Selve idéen er ikke problemet. Det, der sker bagefter, er — og den del bliver sjældent nævnt af den, der sælger dig appen.

Mobilapp-industrien har i ti år målt præcis, hvad der sker med en installation: hvor mange der åbner den, hvor mange der stadig er der efter en måned, hvor mange der vender tilbage efter tre. Disse tal er hårde, offentlige og bemærkelsesværdigt konsistente — og næsten aldrig anvendt på en enkelt restaurant.

Denne artikel gør netop det, i fire tal: hvad en app reelt koster at bygge og vedligeholde, hvor stor en andel af dine egne gæster der realistisk installerer den, hvor mange af dem der stadig åbner den efter 30 og 90 dage, og — det spørgsmål, der faktisk betyder noget — hvor mange ekstra besøg der kræves, før den er tjent hjem. Nederst indtaster du dine egne tal i en beregner, der bruger nøjagtig samme matematik som resten af artiklen.

Konklusionen er hverken "aldrig" eller "altid". For en selvstændig restaurant med ét sted er svaret næsten altid nej — tallene nedenfor viser præcis hvorfor. For en gruppe med flere adresser eller et leveringstungt koncept med reel gentagelsesvolumen kan det samme regnestykke gå op. Forskellen ligger ikke i ambitionen, den ligger i skalaen.

Den ultimative guide Restaurantteknologi & Data: 6 Trin fra 7 Værktøjer til 1 System Fra et enkeltstående kassesystem til ét integreret system: den komplette guide til teknologivalg, der faktisk betaler sig. Åbn guiden

1. Hvad det koster at bygge en app — og at blive ved med at betale for den

Et tilbud på en "simpel" bestillings- og loyalitetsapp til ét sted svinger hos specialiserede bureauer typisk mellem cirka 8.000 € og 25.000 €, afhængigt af hvor meget af dit eksisterende system der skal bygges ind. Tilføj reservationer, levering sporing eller et mere omfattende loyalitetsprogram, og det stiger hurtigt mod 40.000-80.000 € — og der begynder regningen først. Sammenlign det ærligt med det, der allerede står på din liste over softwareabonnementer: en app er sjældent den første omkostning, du vil tilføje.

Oven i byggeomkostningen kommer to tilbagevendende omkostninger, som intet tilbud nævner først. Apple opkræver cirka 92 € om året for en udviklerkonto, uden hvilken ingen iOS-app nogensinde går live — undlader du at betale et år, forsvinder din app fra App Store, uanset hvor mange gæster der allerede bruger den. Google opkræver et engangsbeløb på 23 € for en Play Console-konto. Lille beløb, men det er det første af mange: hver større iOS- eller Android-opdatering tvinger en ny gennemgangsrunde igennem, og en app, der ikke er opdateret i to år, ender med at blive afvist eller simpelthen ikke til at finde i butikken.

Der er to billigere veje, og begge fortjener en ærlig omtale, før du læser videre. En progressive web app (PWA) — "føj til hjemmeskærm" direkte fra din eksisterende hjemmeside — koster en brøkdel af en native app, fordi der hverken er App Store-gennemgang, to separate kodebaser eller en årlig Apple-regning involveret. Og hvis det reservations- eller bestillingssystem, du allerede bruger, tilbyder en app som en indbygget funktion, er dens marginale omkostning nul: du betaler allerede for den, uanset om du bruger den.

Læg det sammen: 900 kr. om året til Apple, 200 kr. som engangsbeløb til Google — før der overhovedet er skrevet en eneste linje kode, og uden nogen garanti for, at en eneste gæst nogensinde åbner den.

2. Hvor mange af dine gæster der reelt installerer den

Spørg et app-bureau om installationsraten, og svaret forbliver vagt: "det kommer an på". Spørg de loyalitetsplatforme, der bygger selvstændige restaurantapps, om deres egne tal, og svaret bliver mere konkret — men det er et tal med en adresse. Udbydere af loyalitetsapps rapporterer typisk en installationsrate på 10-20%, og den andel måles på deres bedste gæster: mennesker, der allerede er stamgæster. Det er samme fælde som med selvbetjeningskiosker: tiltrækkende teknologi, der kun betaler sig for en meget specifik del af dine gæster.

Det er problemet. De 10-20% er ikke en procentdel af alle dine gæster, det er en procentdel af dine stamgæster — og stamgæster er i sig selv allerede et mindretal. Restaurantundersøgelser placerer konsekvent andelen af gæster, der aldrig vender tilbage, omkring 70-77%, og tilskriver cirka 65-80% af omsætningen til de gæster, der vender tilbage. Med andre ord: den gruppe, der overhovedet er kandidat til at installere en app, udgør selv kun en femtedel til en fjerdedel af hele din gæstebase.

Læg disse to tal oven på hinanden, og andelen af HELE din gæstebase, der installerer appen, falder til lave encifrede procenter — ikke ti, langt mindre tyve. På tusind gæster er det groft to hundrede og tyve stamgæster, hvoraf cirka hver syvende installerer appen: trediveogtreotyve mennesker. Det er det realistiske udgangspunkt, ikke det optimistiske tal på tilbuddet.

På 1.000 gæster, med andelene ovenfor. Hver søjle er en andel af det forrige trin.

Gæster i din base

1.000

Stamgæster blandt dem (~22%)

220

Installerer appen (~15% af stamgæsterne)

33

Åbner den igen på dag 1 (~25%)

8

Stadig aktive på dag 90 (~3,5%)

1

Det er vejledende tal, ikke en lov: et sted med reelt loyale leveringsgæster opnår en højere andel stamgæster, et med mange turister en lavere. Mønstret — en stejl tragt fra gæst til installation til aktiv brug — bekræftes i næsten alle undersøgelser.

3. Hvem der stadig åbner appen efter 30 og 90 dage

En installation er ikke en bruger. Mobilapp-industrien har målt dette i årevis via kohortekurver — hvor mange af dem, der installerede på dag nul, vender tilbage senere — og mønstret er bemærkelsesværdigt konsistent, uanset app-kategori. Business of Apps og Adjust rapporterede for 2026 en gennemsnitlig dag-1-retention på cirka 25%: af alle der installerer, åbner cirka hver fjerde nogensinde appen en anden gang.

Derfra accelererer faldet. De samme kilder sætter den gennemsnitlige dag-30-retention til 5-7%, og på det tidspunkt har over 90% af alle brugere allerede opgivet appen. Ved dag 90 — det tidspunkt, hvor en rabat til andet besøg reelt burde begynde at betale sig — ligger retentionen i de fleste kategorier et sted mellem 3 og 5%. Det er ikke uheld hos én sjusket udvikler; det er gennemsnittet på tværs af tusindvis af apps i snesevis af kategorier.

Oversæt det til de trediveogtreotyve installationer fra det forrige tal, og tre måneder senere er der cirka én aktiv bruger tilbage. Ikke én ud af trediveogtreotyve procent — én person. Det er virkeligheden bag "vi bygger en app, så gæsterne kommer tilbage": sandsynligheden for, at en tilfældig gæst stadig åbner den på dag 90, ligger tæt på én ud af tusind.

4. Hvor mange ekstra besøg der skal til for at hvile i sig selv

En app tjener kun sig selv ind, hvis en aktiv bruger kommer oftere, end de ville have gjort uden den — ikke oftere end gennemsnittet, men oftere end de alligevel ville være kommet. Den forskel findes i ingen offentliggjort branchestandard: ingen rapport fortæller dig, hvor mange ekstra besøg én app-bruger reelt genererer, fordi det varierer efter sted, koncept og tilbud.

Det, vi ved, kan vi stille op mod hinanden. Tag byggeomkostningen, del den med dit gennemsnitlige forbrug pr. besøg, og du får det samlede antal ekstra besøg, appen skal generere for at tjene sig selv ind. Del det igen med antallet af aktive brugere, der er tilbage efter 90 dage, og det bliver klart, hvor mange ekstra besøg om måneden hver tilbageværende bruger skulle lave — et tal, der for et normalt sted viser sig fuldstændig urealistisk.

For en gennemsnitligt stor selvstændig restaurant strækker tilbagebetalingstiden sig over årtier. Ikke fordi appen ikke er noget værd, men fordi antallet af mennesker, der stadig bruger den ved dag 90, er for lille til at bære en byggeomkostning på flere tusinde euro — selv hvis hver tilbageværende bruger skulle vise sig usandsynligt trofast.

Samme sted, samme installations- og retentionsrater, tre måder at få en app på.

Få bygget en native app ± 50 år

Progressive web app (PWA) ± 47 måneder

Allerede inkluderet i dit system tjent ind med det samme

PWA-søjlen antager samme installations- og retentionsrater som native appen — kun byggeomkostningen er forskellig. I virkeligheden er tærsklen for at trykke "føj til hjemmeskærm" lavere end et download fra en appbutik, så dette er mere en nedre grænse for, hvor hurtigt en PWA tjener sig selv ind, end en øvre.

Når regnestykket rent faktisk går op

Regnestykket ovenfor er skrevet til det sted, som de fleste læsere af denne artikel driver: én adresse, et par tusind gæster, et tilbud i tiere af tusinder af euro. Skift den skala, og konklusionen kan vende — ikke fordi retentionskurven ændrer sig, men fordi byggeomkostningen ikke ganges op pr. adresse, mens gæstebasen gør.

Tag et leveringstungt koncept med flere adresser og en samlet gæstebase på cirka 50.000 mennesker, med en højere bestillingsfrekvens og en større andel stamgæster end den gennemsnitlige restaurant — realistisk for en virksomhed, der leverer rutinemæssigt i stedet for lejlighedsvis at tage imod gæster. Samme app, samme tilbud på cirka 485.000 kr., men nu fordelt over en langt større base af aktive brugere.

Med lige så forsigtige antagelser om installation og retention hviler den app i sig selv efter cirka 10 måneder — i stedet for årtier. Forskellen ligger ikke i appen, den ligger i nævneren: ved den skala er der nok aktive brugere tilbage til at bære byggeomkostningen; ved et enkelt selvstændigt sted er der ikke.

Hvad du gør, før du skriver under

At skrive under på et tilbud koster én underskrift. Disse tre skridt koster en time, og de afgør, om den underskrift sparer penge eller koster dem.

Før du beder om et tilbud

• Tæl, hvor mange af dine gæster der reelt er stamgæster — mennesker, der vender tilbage mindst en gang om måneden. Det tal, ikke hele din gæstebase, er det, en app faktisk bygges ud fra.
• Stil dig selv ét spørgsmål: hvad gør appen, som en WhatsApp-udsendelsesliste, et gratis loyalitetskort eller et bogmærke på hjemmeskærmen ikke kan? Hvis det ærlige svar er "intet konkret", er appen en dyr måde at gøre det samme på.
• Åbn beregneren ovenfor med dine egne tal, før du taler med et bureau — så ved du, hvilket svar et tilbud skal give dig, ikke omvendt.

Hvis du alligevel bygger

• Start med en PWA, ikke en native app. Bliver den reelt brugt efter et halvt år, har du beviset, før du laver den tidoblede investering.
• Læg fra dag ét en konkret fordel i appen, der ikke findes andre steder — et stempelkort, der kun optjenes der, en ret, der kun kan ses på forhånd der. Uden en grund til at holde den åben gentager kohortekurven ovenfor sig præcis.
• Sæt 15-20% af byggeomkostningen af om året til vedligeholdelse og butiksopdateringer — det er ikke et ekstra, det er prisen for at forblive live.

Den billigere vej

• Undersøg først, om det reservations- eller bestillingssystem, du allerede bruger — eller overvejer — allerede tilbyder en app som en funktion, ved siden af den anden automatisering, det allerede giver dig. I så fald er den marginale omkostning nul.
• Sammenlign den gratis vej ærligt med tilbuddet: samme push-notifikationer, samme loyalitetsintegration, uden en separat Apple-regning.
• Læs, hvad en sådan indbygget app konkret tilbyder på produktsiden for vores egen app — samme spørgsmål, uden bureauet imellem.

Hverken et nej eller et ja — et regnestykke

Næsten enhver ejer, der læser denne artikel, genkender fornemmelsen af, at en app hører til "et moderne sted". Den fornemmelse er ikke forkert — den er bare ikke en finansiel model. De fire tal ovenfor viser, hvad der sker mellem tilbuddet og det første årsafslutning: en stejl tragt fra gæst til installation til aktiv brug, og en byggeomkostning, der skal fordeles på alt for få tilbageværende brugere.

For en gennemsnitligt stor selvstændig restaurant er svaret næsten altid: ikke nu, ikke native, ikke til den pris. Det er ikke en dom over ambitionen — det er, hvad hele appindustriens kohortekurver forudsiger, anvendt på ét sted i stedet for et massepublikum.

Det, der virker, er samme instinkt — at være tættere på gæsten — uden byggeomkostningen, butiksregningen og den årlige opdateringsforpligtelse. Vores egen app er præcis den vej: samme funktion, som en del af et system, du allerede bruger, uden en anden regning fra et bureau.