I den här artikeln
- 1. Vad det kostar att bygga en app — och att fortsätta betala för den
- 2. Hur stor andel av dina gäster som faktiskt installerar den
- 3. Vem som fortfarande öppnar appen efter 30 och 90 dagar
- 4. Hur många extra besök som krävs för att gå jämnt ut
- När uträkningen faktiskt går ihop
- Vad du gör innan du skriver på
En lokal webbyrå, din kassaleverantör eller en franchisekonsult ställer förr eller senare samma fråga: vill du ha din egen app? Svaret du får är nästan alltid känslomässigt — "var där din gäst är" — och nästan aldrig uträknat på papper. Den här artikeln räknar ut det, med siffrorna som appindustrin själv publicerar.
En native app låter som det logiska nästa steget efter din webbplats: din gäst beställer redan från en skärm, så varför inte också från en ikon på telefonen? Själva idén är inte problemet. Det som händer sedan är det — och den delen nämns sällan av den som säljer dig appen.
Mobilappindustrin har i tio år mätt exakt vad som händer med en installation: hur många som öppnar den, hur många som är kvar efter en månad, hur många som kommer tillbaka efter tre. De siffrorna är hårda, offentliga och anmärkningsvärt konsekventa — och nästan aldrig tillämpade på en enda restaurang.
Den här artikeln gör exakt det, i fyra siffror: vad en app verkligen kostar att bygga och underhålla, hur stor andel av dina egna gäster som realistiskt installerar den, hur många av dem som fortfarande öppnar den efter 30 och 90 dagar, och — frågan som faktiskt betyder något — hur många extra besök som krävs innan den betalar sig själv. Längst ner matar du in dina egna siffror i en kalkylator som använder exakt samma matematik som resten av artikeln.
Slutsatsen är varken "aldrig" eller "alltid". För en fristående verksamhet med ett enda ställe är svaret nästan alltid nej — siffrorna nedan visar exakt varför. För en grupp med flera platser eller ett leveranstungt koncept med genuin upprepad beställningsvolym kan samma matematik gå ihop. Skillnaden ligger inte i ambitionen, den ligger i skalan.
Den ultimata guiden Restaurangteknik & Data: 6 Steg från 7 Verktyg till 1 System Från ett fristående kassasystem till ett integrerat system: den kompletta guiden till teknikval som faktiskt lönar sig. Öppna guiden1. Vad det kostar att bygga en app — och att fortsätta betala för den
En offert för en "enkel" beställnings- och lojalitetsapp för ett ställe varierar hos specialiserade byråer mellan ungefär 8 000 € och 25 000 €, beroende på hur mycket av ditt befintliga system som måste byggas in. Lägg till bokningar, leveransspårning eller ett mer omfattande lojalitetsprogram, och det stiger snabbt mot 40 000-80 000 € — och där börjar räkningen bara. Jämför det ärligt med det som redan står på din lista över mjukvaruprenumerationer: en app är sällan den första kostnaden du vill lägga till.
Ovanpå byggkostnaden kommer två återkommande kostnader som ingen offert sätter först. Apple tar ut cirka 92 € om året för ett utvecklarkonto, utan vilket ingen iOS-app någonsin går live — missa ett års betalning, och din app försvinner från App Store, oavsett hur många gäster som redan använder den. Google tar ut en engångsavgift på 23 € för ett Play Console-konto. Litet belopp, men det är det första av många: varje större iOS- eller Android-uppdatering tvingar fram en ny granskningsrunda, och en app som inte uppdaterats på två år hamnar till slut i att bli avvisad eller helt enkelt omöjlig att hitta i butiken.
Det finns två billigare vägar, och båda förtjänar ett ärligt omnämnande innan du läser vidare. En progressive web app (PWA) — "lägg till på hemskärmen" direkt från din befintliga webbplats — kostar en bråkdel av en native app, eftersom varken App Store-granskning, två separata kodbaser eller en årlig Apple-räkning ingår. Och om bokningssystemet eller beställningssystemet du redan använder erbjuder en app som en inbyggd funktion är dess marginalkostnad noll: du betalar redan för den, oavsett om du använder den eller inte.
Räkna ihop: 1 150 kr om året till Apple, 300 kr som engångsbelopp till Google — innan en enda rad kod ens är skriven, och utan någon garanti för att en enda gäst någonsin öppnar den.
2. Hur stor andel av dina gäster som faktiskt installerar den
Fråga en appbyrå om installationsgraden, och svaret förblir vagt: "det beror på". Fråga lojalitetsplattformarna som bygger fristående restaurangappar om deras egna siffror, och svaret blir mer konkret — men det är en siffra med en adress. Leverantörer av lojalitetsappar rapporterar vanligtvis en installationsgrad på 10-20%, och den andelen mäts på deras bästa gäster: människor som redan är stamgäster. Det är samma fälla som med självbetjäningskiosker: attraktiv teknik som bara lönar sig för en mycket specifik del av dina gäster.
Det är problemet. Dessa 10-20% är inte en procentandel av alla dina gäster, det är en procentandel av dina stamgäster — och stamgäster är i sig själva redan en minoritet. Restaurangforskning placerar konsekvent andelen gäster som aldrig kommer tillbaka runt 70-77%, och tillskriver ungefär 65-80% av omsättningen till gäster som återkommer. Med andra ord: gruppen som ens är kandidat till att installera en app utgör själv bara en femtedel till en fjärdedel av hela din gästbas.
Lägg dessa två siffror ovanpå varandra, och andelen av HELA din gästbas som installerar appen sjunker till låga enstaka procenttal — inte tio, långt mindre tjugo. På tusen gäster är det ungefär tvåhundratjugo stamgäster, varav ungefär en av sju installerar appen: trettiotre personer. Det är den realistiska utgångspunkten, inte den optimistiska siffran på offerten.
På 1 000 gäster, med andelarna ovan. Varje stapel är en andel av föregående steg.
Det är vägledande siffror, inte en lag: ett ställe med verkligt lojala leveransgäster når en högre andel stamgäster, ett med mycket turism en lägre. Mönstret — en brant tratt från gäst till installation till aktiv användning — bekräftas i nästan varje studie.
3. Vem som fortfarande öppnar appen efter 30 och 90 dagar
En installation är inte en användare. Mobilappindustrin har mätt detta i åratal via kohortkurvor — hur många av dem som installerade dag noll som senare kommer tillbaka — och mönstret är anmärkningsvärt konsekvent, oavsett appkategori. Business of Apps och Adjust rapporterade för 2026 en genomsnittlig dag-1-retention på omkring 25%: av alla som installerar öppnar ungefär en av fyra någonsin appen en andra gång.
Därifrån accelererar fallet. Samma källor sätter den genomsnittliga dag-30-retentionen till 5-7%, och vid det laget har över 90% av alla användare redan släppt appen. Vid dag 90 — den punkt där en rabatt för andra besöket verkligen borde börja löna sig — ligger retentionen i de flesta kategorier någonstans mellan 3 och 5%. Det är inte otur för en slarvig utvecklare; det är genomsnittet över tusentals appar, i dussintals kategorier.
Översätt det till de trettiotre installationerna från föregående siffra, och tre månader senare finns ungefär en aktiv användare kvar. Inte en av trettiotre procent — en person. Det är verkligheten bakom "vi bygger en app för att gäster ska komma tillbaka": sannolikheten att en slumpmässig gäst fortfarande öppnar den dag 90 ligger nära en av tusen.
4. Hur många extra besök som krävs för att gå jämnt ut
En app betalar bara sig själv om en aktiv användare besöker oftare än de skulle ha gjort utan den — inte oftare än genomsnittet, utan oftare än de ändå skulle ha kommit. Den skillnaden finns i ingen publicerad branschstandard: ingen rapport talar om hur många extra besök en app-användare verkligen genererar, för det varierar per ställe, koncept och erbjudande.
Det vi vet kan vi ställa mot varandra. Ta byggkostnaden, dela den med din genomsnittliga spending per besök, och du får det totala antalet extra besök appen måste generera för att betala sig själv. Dela det igen med antalet aktiva användare som är kvar efter 90 dagar, och det blir tydligt hur många extra besök i månaden varje kvarvarande användare skulle behöva göra — en siffra som för ett normalt ställe visar sig helt orealistisk.
För en genomsnittligt stor fristående verksamhet sträcker sig återbetalningstiden över decennier. Inte för att appen är värdelös, utan för att antalet människor som fortfarande använder den vid dag 90 är för litet för att bära en byggkostnad på flera tusen euro — även om varje kvarvarande användare skulle visa sig osannolikt lojal.
Samma ställe, samma installations- och retentionsgrader, tre sätt att skaffa en app.
PWA-stapeln antar samma installations- och retentionsgrader som native appen — bara byggkostnaden skiljer sig. I verkligheten är tröskeln för att trycka på "lägg till på hemskärmen" lägre än en nedladdning från en appbutik, så det här är snarare ett golv för hur snabbt en PWA betalar sig själv än ett tak.
Räkna ut det för ditt eget ställe
Siffrorna ovan är genomsnitt. Fyll i din egen gästbas, spending och offert — allt beräknas lokalt i din webbläsare.
—
"Extra besök i månaden tack vare appen" är det enda antagandet här utan publicerad källa — fyll i det försiktigt snarare än hoppfullt. Allt beräknas lokalt i din webbläsare; inget skickas eller sparas.
När uträkningen faktiskt går ihop
Uträkningen ovan är skriven för det ställe som de flesta läsare av den här artikeln driver: en plats, några tusen gäster, en offert i tiotusentals euro. Ändra den skalan, och slutsatsen kan vändas — inte för att retentionskurvan förändras, utan för att byggkostnaden inte multipliceras per plats medan gästbasen gör det.
Ta ett leveranstungt koncept med flera platser och en samlad gästbas på ungefär 50 000 personer, med högre beställningsfrekvens och en högre andel stamgäster än den genomsnittliga restaurangen — realistiskt för en verksamhet som levererar rutinmässigt istället för att ta emot gäster tillfälligt. Samma app, samma offert på ungefär 633 000 kr, men nu fördelad över en mycket större bas av aktiva användare.
Med lika försiktiga antaganden om installation och retention betalar den appen sig själv på ungefär 11 månader — istället för decennier. Skillnaden ligger inte i appen, den ligger i nämnaren: på den skalan finns tillräckligt många aktiva användare kvar för att bära byggkostnaden; för ett enda fristående ställe gör det inte det.
Vad du gör innan du skriver på
Att skriva på en offert kostar en signatur. De här tre stegen kostar en timme, och de avgör om den signaturen sparar pengar eller kostar dem.
Innan du ber om en offert
- Räkna hur många av dina gäster som verkligen är stamgäster — människor som återkommer minst en gång i månaden. Den siffran, inte hela din gästbas, är det en app faktiskt byggs på.
- Ställ dig en enda fråga: vad gör appen som en WhatsApp-utskickslista, ett gratis lojalitetskort eller ett bokmärke på hemskärmen inte kan göra? Om det ärliga svaret är "inget konkret" är appen ett dyrt sätt att göra samma sak.
- Öppna kalkylatorn ovan med dina egna siffror innan du pratar med en byrå — då vet du vilket svar en offert måste ge dig, inte tvärtom.
Om du bygger ändå
- Börja med en PWA, inte en native app. Om den verkligen används efter ett halvår har du bevis innan du gör den tiofaldiga investeringen.
- Lägg från dag ett in en konkret fördel i appen som inte finns någon annanstans — ett stämpelkort som bara samlas där, en rätt som bara syns i förhand där. Utan anledning att hålla den öppen upprepas kohortkurvan ovan exakt.
- Avsätt 15-20% av byggkostnaden om året till underhåll och butiksuppdateringar — det är inget extra, det är priset för att förbli live.
Den billigare vägen
- Kontrollera först om bokningssystemet eller beställningssystemet du redan använder — eller överväger — redan erbjuder en app som en funktion, vid sidan av den andra automatiseringen det redan ger dig. Då är marginalkostnaden noll.
- Jämför den gratis vägen ärligt med offerten: samma push-notiser, samma lojalitetsintegration, utan en separat Apple-räkning.
- Läs vad en sådan inbyggd app konkret erbjuder på produktsidan för vår egen app — samma fråga, utan byrån emellan.
Varken ett nej eller ett ja — en uträkning
Nästan varje ägare som läser den här artikeln känner igen känslan att en app hör till "ett modernt ställe". Den känslan är inte fel — den är bara inte en finansiell modell. De fyra siffrorna ovan visar vad som händer mellan offerten och det första årsbokslutet: en brant tratt från gäst till installation till aktiv användning, och en byggkostnad som måste fördelas på alltför få kvarvarande användare.
För en genomsnittligt stor fristående verksamhet är svaret nästan alltid: inte nu, inte native, inte till det priset. Det är inte en dom över ambitionen — det är vad hela appindustrins kohortkurvor förutspår, tillämpade på ett enda ställe istället för en massmarknad.
Det som fungerar är samma instinkt — att vara närmare gästen — utan byggkostnaden, butiksräkningen och det årliga uppdateringskravet. Vår egen app är exakt den vägen: samma funktion, som en del av ett system du redan använder, utan en andra räkning från en byrå.