Webapps
Wanneer Notion of Airtable genoeg is — en wanneer niet
"Kun je voor ons een eigen platform bouwen?"
Negen van de tien keer is mijn eerste vraag: 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 glanzen
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.
Ik heb klanten die jaren op Airtable draaien en daar blij mee zijn. Dat 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.
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.
We hebben niet direct een nieuwe app gebouwd. Eerst hebben we de Sheet naar Airtable gebracht, met een beetje automatisering. Dat werkte zes maanden.
Daarna pas zijn we naar een eigen app gegaan, omdat de klant zelf online kon reserveren en betalen was een nieuwe eis. 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.
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.