In dit artikel
Een lokaal webbureau, je kassaleverancier of een franchiseadviseur stelt vroeg of laat dezelfde vraag: wil je je eigen app? Het antwoord dat je krijgt is bijna altijd emotioneel — "wees waar je klant is" — en bijna nooit doorgerekend. Dit stuk rekent het wél door, met de cijfers die de app-industrie zelf publiceert.
Een native app klinkt als het logische vervolg op je website: je klant heeft al via een scherm besteld, waarom niet via een icoontje op hun telefoon? Het probleem zit niet in de gedachte, het zit in wat er daarna gebeurt — en dat deel wordt zelden verteld door wie de app verkoopt.
De mobiele-app-industrie meet al tien jaar exact wat er met een installatie gebeurt: hoeveel mensen hem openen, hoeveel er na een maand nog zijn, hoeveel er na drie maanden nog terugkomen. Die cijfers zijn hard, publiek en consistent — en ze zijn bijna nooit toegepast op één enkele horecazaak.
Dit stuk doet dat wel, in vier cijfers: wat een app écht kost om te bouwen én te blijven onderhouden, hoeveel van je eigen klanten hem realistisch installeren, hoeveel daarvan hem na 30 en 90 dagen nog openen, en — de vraag die er echt toe doet — hoeveel extra bezoeken er nodig zijn voor je hem terugverdiend hebt. Onderaan zet je je eigen cijfers in een rekenmachine die dezelfde wiskunde gebruikt als de rest van dit artikel.
De conclusie is niet "nooit" en niet "altijd". Voor een zelfstandige zaak met één locatie is het antwoord bijna altijd nee — de cijfers hieronder tonen precies waarom. Voor een groep met meerdere locaties of een bezorgconcept met écht herhaalbestelvolume kan diezelfde wiskunde wél sluiten. Het verschil zit niet in de ambitie, het zit in de schaal.
De ultieme gids Restauranttechnologie: 6 Stappen van 7 Tools naar 1 Systeem Van los kassasysteem tot één geïntegreerd systeem: de complete gids voor technologiekeuzes die renderen. Open de gids1. Wat een app kost om te bouwen — en te blijven betalen
Een offerte voor een "eenvoudige" bestel- en loyaliteitsapp voor één zaak schommelt bij gespecialiseerde bureaus tussen ruwweg € 8.000 en € 25.000, afhankelijk van hoeveel van je bestaande systeem erin moet worden gebouwd. Zodra reserveringen, bezorgtracking of een uitgebreider loyaliteitsprogramma erbij komen, loopt dat snel op richting € 40.000 tot € 80.000 — en daar begint de rekening pas. Vergelijk dat eerlijk met wat er al op je lijst van software-abonnementen staat: een app is zelden de eerste kost die je erbij wilt.
Boven op de bouwkost komen twee terugkerende kosten die geen enkele offerte vooraan zet. Apple rekent €92 per jaar voor een Developer-account, zonder welke geen enkele iOS-app ooit live gaat — betaal je één jaar niet, dan verdwijnt je app uit de App Store, ongeacht hoeveel klanten hem al gebruiken. Google rekent eenmalig €23 voor een Play Console-account. Klein bedrag, maar het is de eerste van vele: elke grote iOS- of Android-update dwingt een nieuwe review-ronde af, en een app die twee jaar niet is bijgewerkt, wordt op termijn geweigerd of gewoon onvindbaar in de winkel.
Er zijn twee goedkopere routes, en ze verdienen allebei een eerlijke vermelding voordat je verder leest. Een progressive web app (PWA) — "zet mij toe aan je startscherm" vanaf je bestaande website — kost een fractie van een native app, omdat er geen appstore-review, geen twee aparte codebases en geen jaarlijkse Apple-rekening bij komt. En als het reserverings- of bestelsysteem dat je al gebruikt een eigen app als functie aanbiedt, is de marginale kost daarvan nul: je betaalt hem al, of je hem nu gebruikt of niet.
Reken mee: € 90 per jaar voor Apple, € 23 eenmalig voor Google — vóór er één regel code geschreven is, en zonder garantie dat één klant hem ooit opent.
2. Hoeveel van je klanten hem écht installeren
Vraag een app-bureau naar het installatiepercentage en het antwoord blijft vaag: "dat hangt ervan af". Vraag de loyaliteitsplatformen die standalone restaurant-apps bouwen naar hún eigen cijfers, en het antwoord is concreter — maar het is ook een cijfer met een adres. Leveranciers van loyaliteits-apps rapporteren doorgaans 10 tot 20% installatiegraad, en dat percentage wordt gemeten op hun beste klanten: mensen die al vaste gasten zijn. Het is dezelfde valkuil als bij zelfbestelkiosken: aantrekkelijke technologie die pas rendeert bij een heel specifiek publiek.
Dat is het probleem. Die 10 tot 20% is geen percentage van al je klanten, het is een percentage van je stamgasten — en stamgasten zijn zelf al een minderheid. Restaurantonderzoek wijst consistent uit dat ruwweg 70 tot 77% van alle gasten nooit terugkomt, en dat zo'n 65 tot 80% van de omzet van de resterende, terugkerende klanten komt. Met andere woorden: de groep die überhaupt kandidaat is om een app te installeren, is zelf al maar een vijfde tot een kwart van je volledige klantenbestand.
Stapel die twee cijfers op elkaar en het percentage van je volledige klantenbestand dat een app installeert, zakt naar enkele procenten — niet naar tien, laat staan twintig. Op duizend klanten zijn dat ruwweg tweehonderdtwintig stamgasten, waarvan gemiddeld een op de zeven de app installeert: drieëndertig mensen. Dat is de realistische instap, niet het optimistische cijfer dat op de offerte staat.
Op 1.000 klanten, met de cijfers hierboven. Elke balk is een aandeel van de vorige stap.
De cijfers zijn richtcijfers, geen wet: een zaak met echt loyale bezorgklanten haalt een hoger stamgastenaandeel, een zaak met veel toeristen een lager. Het patroon — een steile trechter van klant naar installatie naar actief gebruik — blijft overeind in vrijwel elk onderzoek.
3. Wie de app na 30 en 90 dagen nog opent
Een installatie is geen gebruiker. De mobiele-app-industrie meet dit al jaren via cohortcurves — hoeveel van de mensen die op dag nul installeerden, later nog terugkomen — en het patroon is opvallend consistent, ongeacht de categorie app. Business of Apps en Adjust rapporteerden voor 2026 een gemiddelde dag-1-retentie van ongeveer 25%: van wie installeert, opent ruwweg één op de vier de app ooit nog een tweede keer.
Daarna versnelt het verval. Diezelfde bronnen leggen de gemiddelde dag-30-retentie op 5 tot 7%, en meer dan 90% van alle gebruikers heeft de app dan al losgelaten. Tegen dag 90 — het moment waarop een tweede-bezoek-korting pas écht zou moeten renderen — ligt de retentie in de meeste categorieën ergens tussen de 3 en 5%. Dat is geen slordigheid van één ontwikkelaar; het is het gemiddelde over duizenden apps in tientallen categorieën.
Vertaal dat naar de drieëndertig installaties uit het vorige cijfer, en er blijft, drie maanden later, ongeveer één actieve gebruiker over. Niet één op de drieëndertig procent — één persoon. Dat is de realiteit achter "we bouwen een app om klanten te laten terugkomen": de kans dat een willekeurige klant hem op dag 90 nog opent, ligt in de buurt van één op de duizend.
4. Hoeveel extra bezoeken je nodig hebt om quitte te spelen
Een app verdient zichzelf alleen terug als een actieve gebruiker vaker langskomt dan hij zonder de app had gedaan — niet vaker dan gemiddeld, vaker dan hij tóch al zou zijn gekomen. Dat verschil bestaat nergens in een gepubliceerde industriestandaard: geen enkel rapport zegt je hoeveel extra bezoeken één app-gebruiker écht oplevert, omdat dat per zaak, per concept en per aanbod verschilt.
Wat we wél weten, zetten we tegenover elkaar. Neem de bouwkost, deel ze door je gemiddelde besteding per bezoek, en je krijgt het aantal extra bezoeken dat de app in totaal moet opleveren om zichzelf terug te betalen. Deel dat weer door het aantal actieve gebruikers dat er na 90 dagen nog is, en het wordt duidelijk hoeveel extra bezoeken per maand elke overgebleven gebruiker zou moeten maken — een cijfer dat voor een normale zaak volstrekt onrealistisch hoog uitvalt.
Voor een zelfstandige zaak van gemiddelde grootte loopt de terugverdientijd op tot decennia. Niet omdat de app niets waard is, maar omdat het aantal mensen dat hem nog gebruikt tegen dag 90 te klein is om een bouwkost van duizenden euro's te dragen — zelfs als elke overblijvende gebruiker onwaarschijnlijk trouw zou zijn.
Zelfde zaak, zelfde installatie- en retentiecijfers, drie manieren om aan een app te komen.
De PWA-balk gaat uit van dezelfde installatie- en retentiecijfers als de native app — enkel de bouwkost verschilt. In werkelijkheid ligt de drempel om "toevoegen aan startscherm" te tikken lager dan een appstore-download, dus dit is eerder een ondergrens voor hoe snel een PWA terugverdiend is dan een bovengrens.
Reken het door voor jouw zaak
De cijfers hierboven zijn gemiddelden. Vul je eigen klantenbestand, besteding en offerte in — alles rekent lokaal in je browser.
—
Het cijfer "extra bezoeken per maand dankzij de app" is de enige aanname hier zonder gepubliceerde bron — vul liever voorzichtig dan hoopvol in. Alles rekent lokaal in je browser; er wordt niets verstuurd of bewaard.
Wanneer de wiskunde wél sluit
De rekensom hierboven is geschreven voor de zaak die de meeste lezers van dit artikel runnen: één locatie, een paar duizend klanten, een offerte van een paar tiende duizend euro. Verander die schaal en de conclusie kan omslaan — niet omdat de retentiecurve anders wordt, maar omdat de bouwkost niet per locatie wordt vermenigvuldigd terwijl het klantenbestand dat wél doet.
Neem een bezorgconcept met meerdere locaties en een gecombineerd klantenbestand van rond de 50.000 mensen, met een hogere bestelfrequentie en een hoger aandeel stamgasten dan de doorsnee restaurantzaak — realistisch voor wie regelmatig bezorgt in plaats van sporadisch tafelt. Dezelfde app, dezelfde offerte van ongeveer € 50.000, maar nu gedeeld over een veel grotere basis actieve gebruikers.
Met even voorzichtige aannames over installatie en retentie speelt die app binnen ongeveer 10 maanden quitte — in plaats van decennia. Het verschil zit niet in de app, het zit in de noemer: bij die schaal zijn er genoeg overgebleven actieve gebruikers om de bouwkost te dragen, bij één zelfstandige zaak niet.
Wat je doet vóór je tekent
Een offerte tekenen kost één handtekening. Deze drie stappen kosten een uur, en ze bepalen of die handtekening geld bespaart of wegneemt.
Voor je een offerte vraagt
- Tel hoeveel van je klanten écht stamgasten zijn — mensen die minstens maandelijks terugkomen. Dat cijfer, niet je volledige klantenbestand, is waarop een app wordt gebouwd.
- Vraag jezelf één zin af: wat doet de app dat een WhatsApp-lijst, een gratis loyaliteitskaart of een bladwijzer op het startscherm niet kan? Als het antwoord "niets concreets" is, is de app een dure manier om hetzelfde te doen.
- Zet de rekenmachine hierboven open met je eigen cijfers vóór je met een bureau spreekt — dan weet je welk antwoord je een offerte moet geven, niet omgekeerd.
Als je toch bouwt
- Begin met een PWA, niet met een native app. Als die na een half jaar écht gebruikt wordt, heb je bewijs vóór je de tienvoudige investering doet.
- Zet vanaf dag één een concreet voordeel in de app dat nergens anders staat — een stempelkaart die alleen daar spaart, een gerecht dat alleen daar eerder zichtbaar is. Zonder reden om hem open te houden, herhaalt de cohortcurve hierboven zich exact.
- Reserveer 15 tot 20% van de bouwkost per jaar voor onderhoud en appstore-updates — dat is geen extra, dat is de prijs om live te blijven staan.
De goedkopere route
- Kijk eerst of het reserverings- of bestelsysteem dat je gebruikt — of overweegt — een app al als functie aanbiedt naast de andere automatisering die het je bespaart. Dan is de marginale kost nul.
- Vergelijk die kosteloze route eerlijk met de offerte: dezelfde push-meldingen, dezelfde loyaliteitsintegratie, zonder een aparte rekening bij Apple.
- Lees na wat zo'n ingebouwde app concreet biedt op de productpagina van onze eigen app — dezelfde vraag, zonder het bouwbureau ertussen.
Geen nee, geen ja — een rekensom
Bijna elke uitbater die dit artikel leest, herkent het gevoel dat een app hoort bij "een moderne zaak". Dat gevoel is niet fout — het is alleen geen rekenmodel. De vier cijfers hierboven laten zien wat er gebeurt tussen de offerte en de eerste jaarafsluiting: een steile trechter van klant naar installatie naar actief gebruik, en een bouwkost die met te weinig overgebleven gebruikers moet worden gedeeld.
Voor een zelfstandige zaak van gemiddelde grootte is het antwoord bijna altijd: niet nu, niet native, niet voor die prijs. Dat is geen oordeel over de ambitie — het is wat de cohortcurves van de hele app-industrie voorspellen, toegepast op één horecazaak in plaats van op een miljoenenpubliek.
Wat wél werkt, is hetzelfde gevoel — dichter bij je klant staan — zonder de bouwkost, de appstore-rekening en de jaarlijkse update-verplichting. Onze eigen app is precies die route: dezelfde functie, als onderdeel van een systeem dat je toch al gebruikt, zonder een tweede factuur van een bouwbureau.