Wanneer moet je géén app bouwen?

“We willen een app bouwen” is voor veel founders een logisch klinkende zin. Mobiele apps voelen als het bewijs dat een product serieus is. Ze hebben een icoon. Ze staan in een store. Ze kunnen gepusht en geüpdatet worden.

In de meeste vroege producten is een app niet het juiste antwoord. Het is het duurste antwoord. Op een probleem dat eerst goedkoper getest kan worden.

Dit artikel staat stil bij wanneer je géén app moet bouwen, welke alternatieven sneller leren, en welke signalen wél een goede aanleiding zijn om aan een app te beginnen.

App vs webapp vs landingpage

Er zijn grofweg drie niveaus van techniek in een vroeg product. Ieder niveau heeft zijn eigen kosten, snelheid en leerritme.

Een landingpagina. Een statische pagina die uitlegt wat je aanbiedt, vraagt om aanmelding of een gesprek, en geen functionaliteit bevat. Te bouwen in dagen. Verandert iedere keer dat je iets nieuws leert. Geschikt om vraag te toetsen, niet om iets te leveren.

Een mobielvriendelijke webapp. Een echte applicatie die werkt in een mobiele browser. Klanten kunnen actie ondernemen, data invoeren, betalen. Te bouwen in weken. Eén codebase voor desktop én mobiel. Aan te passen op de dag dat je iets nieuws leert.

Een native app. Een iOS- en Android-app die via de app stores wordt gedistribueerd. Maanden om te bouwen. Twee codebases. Review-proces bij elke update. Beperkte mogelijkheid om snel te wijzigen.

De vraag is niet “welke moet ik bouwen?”. De vraag is “welk niveau past bij wat ik in deze fase wil leren?”. Voor de meeste vroege producten is dat een landingpagina gevolgd door een mobielvriendelijke webapp. Niet een native app.

App stores

App stores zijn geen neutrale distributiekanalen. Ze hebben regels, percentages, review-processen en hun eigen mening over wat een goede app is. Voor een vroege startup brengt dat een aantal verplichtingen mee die niet altijd zichtbaar zijn op het moment dat je voor een app kiest.

Een developer-account per platform (€/jaar). Review-tijd waarin een release vast staat. Een commissie van 15-30% op in-app betalingen. Regels over wat wel en niet mag, die per update kunnen veranderen. Een afwijzing die je launch met een week kan vertragen.

Voor producten waar het verdienmodel direct met in-app aankopen werkt, accepteer je die voorwaarden bewust. Voor producten waar de eerste paar maanden vooral over leren gaan, zijn ze pure kosten zonder directe baat.

Onderhoud

Een mobielvriendelijke website pas je aan en je gebruikers zien direct de nieuwe versie. Een app moet door een release-cyclus heen, bouwen, testen, indienen, wachten op review, vrijgeven, en je gebruikers moeten daarna nog updaten.

Dat betekent dat in een app twee versies tegelijk in omloop zijn: de versie die gisteren is vrijgegeven en de versie die mensen nog niet hebben geüpdatet. Je moet altijd nadenken over wat oudere versies nog ondersteunen, of je een nieuwe feature beschikbaar maakt voor oudere apps, en hoe je communiceert dat een update nodig is.

In een vroege fase wil je vooral kunnen veranderen. Niets dwingt je sneller tot minder veranderen dan een installed base aan oude app-versies.

Updates

Updates die kritisch zijn (bijvoorbeeld een security-fix) zijn in een app trager te verspreiden dan in een webapp. Een review duurt soms uren, soms dagen. Tijdens die periode zit je vast met de oude versie in productie.

Voor producten met directe financiële of gevoelige interactie kan dat tijdsverschil belangrijk zijn. Voor producten waar de eerste klanten vooral over feedback gaan, is het frustrerend.

Validatie

De grootste reden om geen app te bouwen in een vroege fase: validatie kost meer cycli. Een mobielvriendelijke webapp pas je aan, klanten zien morgen de nieuwe versie. Een app pas je aan, klanten zien hem over weken pas, als ze updaten.

Vroege producten leren door cycli te draaien. Elke cyclus die je niet kunt afsluiten omdat je vastzit aan een release-proces, is een week van leren die je niet kunt doen. In een fase waarin je elke week iets wilt aanpassen, is een app dus eigenlijk een rem.

Gebruikersgedrag

Voor de meeste vroege producten gaat het er niet om of klanten dagelijks vele keren terugkomen. Het gaat erom of ze één keer komen, hun eerste actie uitvoeren, en gemotiveerd genoeg zijn om een tweede keer te komen.

Voor die test is geen app nodig. Een link in een mail, een QR-code op een fysiek punt, of een aanbeveling via een collega, een mobiele webversie pakt dat allemaal op. Een gebruiker die graag binnen 5 seconden iets wil proberen, doet dat liever dan dat hij iets installeert.

Wanneer een app wél logisch is

Er zijn momenten waarop een native app wel de juiste keuze wordt. De drie meest voorkomende:

• Hardware-toegang die een browser niet heeft. Achtergrondprocessen, lokale opslag van significante grootte, BLE-koppelingen met fysieke apparaten, AR-functies of intensieve camera-integratie. Voor sommige use cases gaat dit niet om een website heen.
• Frequent dagelijks gebruik door dezelfde gebruikers. Bij producten die mensen elke dag tien keer openen, bankapps, ride-hailing, sociale netwerken, verlaagt een app de drempel per gebruik genoeg om de bouw te rechtvaardigen.
• Aantoonbare retentie-impact van native presence. Als je hebt vastgesteld dat je product werkt en wilt schalen, kan een app store-presence helpen met ontdekking en retentie. Maar pas dan, niet voor je dat hebt vastgesteld.

In al deze gevallen ligt aan de beslissing een werkend product en bestaande klanten ten grondslag. De app is geen middel om uit te vinden of het product werkt. De app is een investering in een product waarvan al bewezen is dat het werkt.

Waarom een mobielvriendelijke webversie vaak eerst beter is

Voor de meeste vroege producten geldt: een mobielvriendelijke webversie test al je belangrijkste aannames, levert al je belangrijkste klantwaarde, en kost een fractie van een native app.

Wat een webversie meestal niet doet, is mensen dwingen om je product een vaste plek in hun telefoon te geven. Dat klinkt als een nadeel. Voor een vroege startup is het meestal een voordeel, je test of mensen vrijwillig terugkomen, niet of ze een icoon naast hun bankapp accepteren.

Pas als je hebt vastgesteld dat klanten vrijwillig terugkomen, is een app een logische volgende stap. Voor die tijd is een app vooral een dure manier om uit te zoeken wat een mobiele website goedkoper had verteld.

Waarom een mobiele website vaak wint van een app gaat verder in op dat onderscheid.

---

Sta je voor deze beslissing?

Stuur me kort de context of plan een gratis gesprek. Dan kijken we samen wat de meest verstandige volgende stap is voor je tijd, geld of focus vastlegt.

Plan een gratis gesprek → · Mail direct: hello@yourstartup.expert