"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.

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.

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 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 de migratie liep, maand per maand

Voor wie herkent dit patroon, hier het volledige tijdspad.

Maand 0: alleen Google Sheet. Eén tabblad per maand, handmatig bijgehouden. Klant belt, boeking in de sheet, 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, geen kosten voor de klant behalve de Airtable-licentie van € 20 per maand. 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 hun eigen openstaande items zien. De klant vindt het een grote verbetering tegenover de sheet.

Maand 3 tot 5: opschaling. Van 40 naar 120 boekingen per maand. Airtable trekt dit nog goed. Er ontstaat irritatie over twee punten: klanten moeten handmatig gebeld worden voor betaling, en de boekingsbevestiging voelt alsof het van Airtable komt, niet van het bedrijf.

Maand 6: de grens. Online betalen is niet te bouwen zonder eigen backend. Airtable's integratie met Mollie via Make is brekelijk en duur. De klant wil een eigen klantportaal: inloggen, boekingen bekijken, betalen, herboeken.

Maand 7 tot 9: eigen app. Wij bouwen op Next.js met een PostgreSQL-database. Alle Airtable-data gemigreerd in één script. Klanten krijgen een login. Mollie-integratie voor betaling. Alles onder het eigen merk.

Maand 10: live. De Airtable-setup draait nog parallel één maand voor verificatie, daarna uit. Totale kosten van de eigen app: € 13.000 eenmalig, € 50 per maand hosting.

Vanaf maand tien is de stack kleiner, goedkoper en veel stabieler. Én het bedrijf heeft 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 volledige 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)

Ik heb dit ingezet voor twee klanten als tussenstap. Een half jaar later draaiden beiden op volledig eigen code. De hybride setup was de leerfase waarin duidelijk werd wat de eigen app écht moest 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.

Sparren over jouw setup? →

Zie ook: Wanneer een eigen webapp goedkoper is dan drie SaaS-tools. Of bekijk direct de webapps-aanpak.