Data-platform · Freelance
BI-platform voor een hotel- en horecagroep
Eén set cijfers uit zes bronsystemen, zonder dat er ook maar één persoonsgegeven kan weglekken.
- Rol
- architect en lead developer (freelance)
- Periode
- augustus 2026 – heden
- Opdrachtgever
- Hotel- en horecagroep (freelance)
- Type
- BI-platform, in aanbouw
- Kerntechnologie
- Supabase (PostgreSQL), dbt, React, TypeScript
Over het project
Een hotel- en horecagroep met meerdere hotels en restaurants wilde kunnen sturen op actuele cijfers. Het platform dat daarvoor nodig is, ontwerp en bouw ik zelf, van het ophalen van de brondata tot het dashboard waar het management mee gaat werken. Het is nog in aanbouw: een groot deel draait al, de rest volgt.
De uitdaging
De cijfers zaten verspreid over zes systemen die niet met elkaar praten. Het ging om hotelreserveringen, boekhouding, tafelreserveringen, personeelsplanning, prijsstrategie en online marketing. Wie wilde weten hoe een hotel ervoor stond, keek in zes schermen, rekende zelf en kwam elke keer op een net iets ander getal uit. Daar kwam bij dat elk systeem zijn eigen API heeft, met een eigen manier van inloggen, eigen limieten en een eigen datamodel. De vraag aan mij was één dashboard met één set cijfers, waarin iedere gebruiker precies de data ziet die hij mag zien.
Wat ik heb gebouwd
Een dataplatform in vijf lagen, een zogeheten medallion-architectuur. Elke laag heeft één taak: 1. Raw: de brondata zoals die binnenkomt. Gastgegevens gaan er al bij het ophalen uit. 2. Staging: hier wordt de data opgeschoond en per bron in een vaste vorm gegoten. 3. Core: de bronnen worden aan elkaar gekoppeld via begrippen die ze delen, zoals hotel, afdeling en kostensoort. 4. Mart: feitentabellen per dag en per hotel. 5. Public: de Semantic Layer. Dit is de enige laag die van buitenaf bereikbaar is.
Belangrijkste functionaliteit
Privacy by design.
Wat niet nodig is, komt er ook niet in. Alleen de bovenste laag is bereikbaar, en Row Level Security (beveiliging per rij, in de database zelf) zorgt dat iedere gebruiker alleen zijn eigen hotel of afdeling ziet. Een fout in de front-end kan daar dus niet omheen.
Strikt alleen-lezen.
Het platform kan niets terugschrijven naar de systemen van de klant. Dat is afgedwongen in de code, en mijn AI-tooling heeft dezelfde beperking.
Tests als poort.
De dashboardlaag wordt pas bijgewerkt als alle datatests slagen. Zit er een fout in de brondata, dan komt die dus nooit ongemerkt op het dashboard terecht.
Eén definitie per KPI.
Omzet, bezettingsgraad en loonkostenpercentage hebben elk precies één definitie. Dat legt ook de basis voor een AI-assistent die later vragen beantwoordt met diezelfde definities en dezelfde toegangsregels.
Snel.
Dankzij incrementele modellen, die alleen nieuwe of gewijzigde data verwerken, en nieuwe indexen leest de staging-laag zo'n 99 % minder data. Het zwaarste model deed er eerst 41 seconden over, nu minder dan één seconde.
Hoe het werkt
Elke bron wordt periodiek opgehaald en loopt dan laag voor laag omhoog. De bovenste laag wordt alleen bijgewerkt als alle tests slagen, en het dashboard leest uitsluitend uit die laag. Komt er later een AI-assistent bij, dan gaat die op precies dezelfde manier te werk, met dezelfde KPI's en dezelfde toegangsregels.
Hoe ik bouw
Bij mij komt het ontwerp eerst en de code daarna. Ik heb tien dashboardpagina's uitgewerkt en met de opdrachtgever doorgesproken voordat er een regel front-end bestond. Pas toen heb ik ze vertaald naar een componentbibliotheek. Voor de projectkennis, zoals architectuurbesluiten, KPI-definities en API-documentatie, bouwde ik een eigen kennisbank met een MCP-server. MCP is een standaard waarmee AI-tools bij externe bronnen kunnen. Zo zoeken mijn tools gericht en hoeven ze geen hele documenten door te lezen. AI maakt me sneller, maar de architectuur en de keuzes maak ik zelf.
Waar het nu staat
Werkt nu
- Vijf van de zes bronnen laden elke dag data.
- De lagen van ruwe data tot Semantic Layer draaien grotendeels live.
- De opdrachtgever heeft de dashboardontwerpen goedgekeurd.
Volgende stap
- De laatste bron aansluiten.
- De goedgekeurde ontwerpen in de app bouwen.
Kerncijfers
6
bronsystemen gekoppeld
5
datalagen
65
dbt-modellen
16
KPI's in het register
4
rollen in het toegangsmodel
−99 %
data-IO in de staging-laag
Gebruikte tools
- Data & back-end
- Supabase (PostgreSQL, Edge Functions, Row Level Security, pg_cron)dbtSQL
- Front-end
- ReactTypeScriptTanStack Start/Router/QueryTailwind CSSshadcn/uiRechartsZod
- Design
- MagicPathLovable
- DevOps
- GitHubGitHub Actionsbun
- Kennisbank & AI
- PythonSQLite FTS5Model Context Protocol (MCP)Claude Code
Wat ik heb geleerd
- 01
Een datawarehouse in lagen ontwerpen: waarin elke laag maar één verantwoordelijkheid heeft.
- 02
Security by design:: beveiliging die in de database zelf zit, in plaats van alleen in de interface.
- 03
Data-engineering met dbt:: incrementele modellen, tests die als kwaliteitspoort werken, en meten hoeveel data er gelezen en geschreven wordt (IO) om dat omlaag te brengen.
- 04
Zes externe API's integreren: , die elk hun eigen authenticatie, limieten en datamodel hebben.
- 05
Een eigen MCP-server bouwen: die mijn AI-tools gericht van projectkennis voorziet.
Staat jouw data ook verspreid over systemen die niet met elkaar praten? Dan denk ik graag met je mee.