Webapps
Wanneer Notion of Airtable genoeg is, en wanneer niet
"Kun je voor ons een eigen platform bouwen?"
Daar hoort een tegenvraag bij: heb je Notion of Airtable al geprobeerd?
Niet om een project af te schudden. Om het juiste gereedschap bij het probleem te leggen.
Waar Notion en Airtable op hun best zijn
Snelle setup. Geen code. Formules die veel aankunnen. Views, filters, relaties tussen tabellen. Gedeelde toegang met rollen.
Voor interne processen (klant-onboarding, content-planning, voorraad-tracking, team-wiki) is dat genoeg. Vaak ruim.
Een setup die op die manier jarenlang meegaat is geen gebrek aan ambitie. Dat is goed gekozen gereedschap.
Wanneer het niet meer past
Vier vragen die bij mij het verschil bepalen:
1. Moet je klant het gebruiken?
Interne tools kunnen rommelig zijn, jij wordt er handig in. Maar zodra je klant door je systeem moet (bestellen, boeken, uploaden), werkt Notion niet meer. Dan heb je een eigen interface nodig die jouw merk draagt en je klant niet hoeft uit te leggen.
2. Heb je veel rijen of hoge frequentie?
Airtable is prima tot een paar duizend rijen per tabel. Boven de 50.000 wordt het traag. Boven de 100.000 wordt het pijnlijk. Als je workload groeit, groeit het probleem mee.
3. Heb je complexe business-logica?
"Stuur een factuur 14 dagen na de laatste betaling, tenzij de klant op plan X zit, dan na 30 dagen, en dan alleen als het bedrag boven € 50 is."
Dat bouw je in Airtable met automations + formules en het werkt. Tot er een uitzondering bij komt. Dan gaat het stuk. Code blijft overzichtelijk waar low-code dichtklapt.
4. Heb je integraties met specifieke partijen?
Mollie, Resend, een boekhoudpakket, een voorraad-API van je leverancier. Dat kan met Zapier / Make in het begin. Maar elke integratie is een extra betaalde tool, een extra plek waar iets kan breken, en een extra maandabonnement.
Op een bepaald punt is één eigen applicatie goedkoper dan vijf tools aan elkaar geplakt.
Vraag vijf: heb je een team dat ermee werkt?
De vier vragen hierboven zijn de meest genoemde. Er is een vijfde die minder vaak gesteld wordt, maar net zo beslissend is.
Hoeveel mensen onderhouden dit systeem?
Een Airtable-setup ontstaat vaak in één hoofd. Die persoon kent elke formule, weet wat er achter elke automation zit, en onthoudt welke veld-naam niet mag veranderen omdat daar iets aan hangt.
Zolang die persoon blijft, werkt het.
Gaat die persoon weg, of wordt de setup door een nieuwe medewerker overgenomen, dan begint het raden. Formules die niemand meer leest. Automations die breken zonder dat iemand weet waarom. Een veld hernoemd en ineens klopt de factuur niet meer.
Voor eigen code is er een andere verdeling. Code is leesbaar voor andere ontwikkelaars. Versiebeheer (Git) laat zien wie wat wanneer heeft veranderd, en waarom. Documentatie hoort bij het vakgebied. Een nieuwe ontwikkelaar is binnen een week productief.
Voor een setup die drie jaar of langer mee moet, en die meerdere mensen moeten kunnen onderhouden, is dat een reëel verschil. Niet op dag één. Wel op dag duizend.
Een voorbeeld uit mijn praktijk
Een klant runde zijn verhuur via een gedeelde Google Sheet, een WhatsApp-groep en e-mails. Dat werkte, voor tien boekingen per maand.
Toen het er 200 werden, begon het te kraken. Sheet-conflicten, dubbel-geboekte data, klanten die geen antwoord kregen.
Ik heb niet direct een nieuwe app gebouwd. Eerst heb ik de Sheet naar Airtable gebracht, met een beetje automatisering. Dat werkte zes maanden.
Daarna pas ben ik naar een eigen app gegaan, omdat zelf online reserveren en betalen een nieuwe eis werd. Dat kon Airtable niet dragen.
Die volgorde (Sheet, Airtable, eigen app) is vaak de juiste. Niet omdat ik eerst weg wil van een opdracht. Omdat je zo precies leert wat de eigen app moet doen.
Hoe zo'n migratie loopt, maand voor maand
Wat hieronder staat is een uitgewerkt scenario en geen verslag van een opdracht. De cijfers erin zijn aannames, gekozen om de volgorde en de kosten inzichtelijk te maken.
Maand 0: alleen Google Sheet. Eén tabblad per maand, handmatig bijgehouden. Iemand belt, de boeking gaat in de sheet, er gaat een WhatsApp-bevestiging terug.
Maand 1: eerste Airtable-setup. Kolommen: klant, datum, artikel, status, opmerking. Formulier voor online aanvragen, auto-mail vanuit Airtable. Installatie: twee dagen, verder geen kosten behalve de Airtable-licentie. De eerste week gaat goed. Tweede week komt er een gebruiker bij die views niet snapt.
Maand 2: toevoegen van automations. Statusveranderingen sturen de juiste e-mails. Een view per medewerker laat alleen de eigen openstaande items zien. Tegenover de sheet is dat een grote verbetering.
Maand 3 tot 5: opschaling. Neem aan dat het aantal boekingen in deze maanden verdrievoudigt. Airtable trekt dat nog goed. Er ontstaat irritatie over twee punten: er moet handmatig gebeld worden voor betaling, en de boekingsbevestiging voelt alsof hij van Airtable komt en niet van het bedrijf.
Maand 6: de grens. Online betalen is niet te bouwen zonder eigen backend, en de koppeling van Airtable aan een betaaldienst via Make is breekbaar en duur. Wat er nodig is, is een eigen klantportaal: inloggen, boekingen bekijken, betalen, herboeken.
Maand 7 tot 9: eigen app. Next.js met een PostgreSQL-database. Alle Airtable-data in één script gemigreerd. Klanten krijgen een login, betalen via Mollie, alles onder het eigen merk.
Maand 10: live. De Airtable-setup draait nog parallel één maand voor verificatie, daarna uit. Reken in dit scenario met € 13.000 eenmalig en € 50 per maand hosting.
Vanaf maand tien is de stack kleiner, goedkoper en stabieler. En er ligt een asset: een eigen platform dat mee kan groeien.
Hybride setup: het bestaat ook
Een minder bekende middenweg: Airtable als backend, eigen frontend erboven.
Airtable biedt een API die je als database kunt benaderen. Een Next.js-app kan direct tegen die API praten en een eigen interface tonen aan klanten.
Wanneer werkt dit goed?
- Je hebt al een werkende Airtable-setup waar je medewerkers goed mee overweg kunnen
- Je wilt klanten wel een eigen, merk-consistent portaal bieden
- Je bent niet klaar om alle logica te migreren naar eigen code
- Je budget voor volledig maatwerk is nog even niet rond
Wanneer niet?
- Je hebt complexe rechten per klant (Airtable-rechtenmodel is beperkt)
- Je hebt veel data of hoge frequentie (Airtable API heeft rate limits)
- Je wilt dingen doen die niet in tabelvorm passen (zoekopdrachten over meerdere tabellen, bijvoorbeeld)
Als tussenstap kan die hybride opzet de leerfase zijn waarin duidelijk wordt wat de eigen app écht moet doen.
Veelgestelde vragen
Kan ik beginnen zonder Notion of Airtable? Soms. Als je vanaf dag één klanten-interface nodig hebt, of als je processen al heel helder zijn. Maar in de meeste gevallen verdien je de extra discipline van het eerst low-code oplossen terug met een veel scherpere eigen app later.
Wat kost het echt om een Airtable-setup goed te krijgen? Een paar honderd euro per maand aan licenties (Airtable Pro, Make, eventueel Softr voor een portaal) plus een of twee werkdagen per maand aan onderhoud door iemand die het snapt. Niet gratis, maar veel minder dan een eigen app, en snel live.
Wanneer is hybride zinvol en wanneer niet? Hybride is zinvol als je intern op Airtable werkt en alleen de klant-interface nieuw wilt. Het is niet zinvol als je ook een nieuwe backend-logica nodig hebt. Dan bouw je dubbel werk.
Hoe verplaats ik alle data als ik overstap? Export uit Notion of Airtable via hun eigen export-functie (CSV of JSON) en import-script in de nieuwe app. Een halve dag werk voor een stabiele setup. Voor grotere sets met gekoppelde tabellen iets meer, maar niet meer dan twee dagen.
De kortste vraag
Voor de lezer die het snel wil: als je klant in je systeem moet, bouw het goed. Als jij erin moet, vraag je je eerst af of je het niet al hebt.
Zie ook: Wanneer een eigen webapp goedkoper is dan drie SaaS-tools. Of bekijk direct de webapps-aanpak.