BI Zonder een Data Lake

De meeste startup BI-projecten beginnen te vroeg en te groots.

Een founder stelt een simpele vraag: "Komen gebruikers van dit kanaal terug na hun eerste run?" Het antwoord zou een query moeten zijn. In plaats daarvan wordt het vaak een platformproject: elke bron koppelen, een warehouse bouwen, events definiëren, identiteiten opschonen, dashboards inrichten en wachten.

Dat werk is uiteindelijk belangrijk. Maar voor een klein team kan het de verkeerde eerste stap zijn. De productdatabase weet al het meeste wat de founder moet weten. Wie zich heeft aangemeld, wie iets heeft uitgevoerd, wat ze gebruikten, hoeveel het kostte, wat mislukte en of ze terugkwamen.

Het echte probleem is niet waar de waarheid zich bevindt. Het is hoe je een agent die waarheid laat analyseren zonder de ruwe productiedatabase bloot te stellen.

Dat is het patroon dat we bij VM0 gebruiken: een gemaskeerde, alleen-lezen Neon-branch die onze agents genoeg waarheid geeft om BI uit te voeren, zonder ze toegang te geven tot data die ze nooit zouden mogen zien.

Het founder-probleem: de vragen komen vóór het datateam

Vroege bedrijven hebben geen gebrek aan vragen. Ze hebben een gebrek aan tijd.

Elke dag wil het founderteam dingen weten als:

• Werden de bezoekers van gisteren echte gebruikers?
• Welke aanmeldkanalen leveren mensen op die daadwerkelijk iets uitvoeren?
• Komen gebruikers na hun eerste run terug na 7 of 30 dagen?
• Welke betaalde accounts worden stil?
• Welke modelroute drijft de kosten?
• Misbruiken proefgebruikers rekenkracht voordat ze converteren?
• Is de productgezondheid beter of slechter geworden sinds gisteren?

Geen van deze vragen is exotisch. Ze vormen het operationele ritme van een startup.

Maar ze beantwoorden met het traditionele BI-handboek zorgt voor veel overhead. Meestal begin je met het verplaatsen van data uit de productdatabase naar een ander systeem. Daarna normaliseer je het, definieer je metrics, bouw je relaties opnieuw op en richt je dashboards in. Het team krijgt een schonere analytics-stack, maar de founder wacht vaak dagen of weken op een antwoord dat als SQL-query had kunnen beginnen.

Voor een kleine startup kan die afweging verkeerd uitpakken. Je hebt geen compleet dataplatform nodig om je eerste 20 operationele vragen te stellen. Je hebt een veilige manier nodig om de bron van de waarheid die je al hebt te bevragen.

De database is al de bron van de waarheid

Bij VM0 bevat de productdatabase de feiten die belangrijk zijn voor veel beslissingen op founder-niveau:

• Organisaties en gebruikers
• Aanmeld- en abonnementsstatus
• Agent-runs en planningen
• Verbruik van credits en gebruiksgebeurtenissen
• Geselecteerde modellen en provider-routes
• Connectorstatus
• Foutstatus en tijdstempels

Die relaties zijn er al. Ze zijn actueler dan elk downstream-dashboard en weerspiegelen hoe het product daadwerkelijk werkt.

Dit is belangrijk omdat veel vroege BI-vragen relationeel zijn. Een founder wil niet alleen pageviews of run-aantallen. Ze willen gedrag over het hele systeem verbinden:

Van de gebruikers die zich via dit kanaal registreerden, hoeveel voerden iets uit op dag nul, en hoeveel kwamen terug na hun eerste run?

Of:

Welke betaalde organisaties hebben de afgelopen 7 dagen niets uitgevoerd, en leken ze daarvoor actief?

Of:

Hoeveel rekenkracht verbruikten nieuwe proefaccounts in hun eerste 6 uur, vóór en nadat we onze abuse patrol aanpasten?

Die vragen passen van nature in de productdatabase. Ze worden veel moeilijker als elk antwoord begint met het verplaatsen van data naar een apart platform.

De onveilige shortcut is ruwe productie-toegang

De verleidelijke shortcut is duidelijk: laat de agent gewoon productie bevragen.

Dat is niet acceptabel.

Een productiedatabase kan het meest gevoelige materiaal van het bedrijf bevatten: e-mailadressen, prompts, chatinhoud, credentials, versleutelde providerstatus, logs, foutmeldingen, API-sleutels en interne operationele gegevens. Zelfs als een agent voorzichtig is, creëert ruwe toegang een grensprobleem. De agent kan te veel zien. Een fout in een query, rapport of screenshot kan informatie lekken die het team nooit wilde blootstellen.

Schrijfrechten zijn nog erger. BI mag productie niet kunnen wijzigen. Een analist, menselijk of agentisch, mag niet met één verkeerde opdracht gebruikersdata veranderen.

De vraag is dus niet of agents SQL kunnen schrijven. Dat kunnen ze. De vraag is of je ze genoeg waarheid kunt geven om nuttig te zijn, terwijl privacy en veiligheid harde randvoorwaarden blijven.

Voor ons zijn die randvoorwaarden het uitgangspunt:

• Agents mogen geen ruwe prompts zien.
• Agents mogen geen ruwe e-mails zien.
• Agents mogen geen credentials of geheimen zien.
• Agents mogen geen gevoelige vrije-tekstlogs zien.
• Agents mogen geen schrijfrechten hebben op de BI-bron.
• Het founderteam moet nog steeds snel praktische operationele vragen kunnen stellen.

Dat is de vorm van het systeem die we nodig hadden.

Het veilige midden: een gemaskeerde, alleen-lezen database

Neon maakt een bruikbaar patroon mogelijk omdat branches goedkope, geïsoleerde kopieën van een Postgres-database zijn. Je kunt een productie-achtige branch maken, deze transformeren en die branch blootstellen in plaats van productie zelf.

Bij VM0 gebruiken we dit om wat wij MaskDB noemen te creëren.

De flow is eenvoudig:

1. Begin bij de productie-Neon-hoofdbranch.
2. Maak op schema een nieuwe branch aan.
3. Installeer PostgreSQL Anonymizer en VM0-specifieke masking-helpers.
4. Pas beveiligingslabels toe op gevoelige kolommen.
5. Voer statische anonimisering uit op de branch.
6. Pas definitieve aangepaste maskers toe voor velden die speciale behandeling vereisen.
7. Maak een masked_readonly-rol met SELECT-toegang aan.
8. Laat agents die rol bevragen, niet productie.

Het belangrijke detail is dat de masking statisch is. Gevoelige waarden worden op de gemaskeerde branch herschreven voordat de agent verbinding maakt. Dit is anders dan elke downstream-query vragen te onthouden wat niet geselecteerd mag worden. De branch zelf is de grens.

In onze MaskDB worden credentials en geheimen verwijderd. E-mails en telefoonnummers zijn gedeeltelijk gemaskeerd. Gebruikersinhoud zoals prompts, chatberichten, schema-prompts en agent-uitvoer wordt verwijderd. Fouttekst wordt teruggebracht tot een klasse in plaats van een volledige stack of melding. Tabellen die nooit in analyses mogen voorkomen, kunnen volledig worden verwijderd.

Tegelijkertijd blijven ondoorzichtige identifiers zoals org_id, user_id en clerk_user_id koppelbaar. Dat maakt BI mogelijk. We hoeven niet dat de agent het e-mailadres of de prompttekst van een persoon kent. We moeten wel weten dat dezelfde organisatie zich registreerde, een taak uitvoerde, credits verbruikte, zich abonneerde, inactief werd of later terugkwam.

Dat evenwicht is het hele punt: maskeer het menselijk leesbare en gevoelige materiaal, behoud de relationele ruggengraat.

Wat agents kunnen doen zodra de grens bestaat

Zodra de gemaskeerde alleen-lezen database bestaat, kan de agent snel nuttig worden.

Hij kan direct vragen stellen op productdata:

• 7- en 30-daagse gebruikersretentie
• Activatie van registratie tot eerste run
• Retentie verankerd op eerste run
• Inactiviteit van betaalde organisaties
• Abonnementsstatus en churn-bewaking
• Modelgebruik per geselecteerd model
• Ingebouwde versus gebruikersprovider-routes
• Verbruik van proef-rekenkracht
• Kosten per run per model
• Fout- en voltooiingspercentage per cohort

Hij kan die databasewaarheid ook combineren met de omliggende systemen.

Onze Morning Brief haalt gegevens uit Plausible, Axiom, Sentry, Google Ads, GitHub en andere operationele bronnen. De database vertelt wat gebruikers en organisaties deden. Plausible vertelt wat er op de site gebeurde. PostHog helpt met productevent-context. Axiom geeft inzicht in logs en request paths. Sentry vangt fouten. Stripe en Clerk verklaren facturatie en identiteit. GitHub toont engineering-output.

Het doel is niet elk hulpmiddel door SQL te vervangen. Het doel is de agent de feiten te laten verbinden waar founders echt om geven.

Bijvoorbeeld:

Betaalde Google-verkeer stuurde gisteren meer bezoekers dan organisch. Bereikten die gebruikers daadwerkelijk hun eerste run, of stopten ze bovenaan de funnel?

Of:

We hebben de proefmisbruik-patrouille aangepast. Verbruikten nieuwe proefaccounts minder rekenkracht in hun eerste uren?

Of:

Deze modelroute is goedkoper per run. Komt dat terug in echt historisch chatgebruik, of alleen in prijstheorie?

Dat zijn geen dashboardvragen. Het zijn operationele vragen. Ze veranderen van week tot week, soms van dag tot dag. Een agent met veilige database-toegang kan ze beantwoorden zonder engineering telkens een nieuw overzicht te laten bouwen.

Een echt voorbeeld: retentie en externe gebruikersgezondheid

Een van onze dagelijkse interne analyses kijkt naar de gezondheid van externe gebruikers over de afgelopen 24 uur.

Het rapport begint bij MaskDB en past dan een strikte uitsluitingsset toe. Interne VM0-organisaties worden verwijderd. Door Clerk geblokkeerde of gelockte spamorganisaties worden verwijderd. Diezelfde uitsluitingsset wordt overal toegepast, ook op registratieaantallen en retentiecohorten, zodat de delers controleerbaar blijven.

Daarna kan de agent een compact operationeel rapport maken:

• Runs en actieve externe organisaties
• Voltooiingspercentage
• Trigger-mix over web, CLI, schema's en niet-Zero-routes
• Modelmix
• Providermodus
• Activiteit van betaalde organisaties
• Inactieve betaalde organisaties
• Nieuwe betaalde aanmeldingen en proeforganisaties
• Churn-bewaking
• 30-daagse gebruikerssegmentatie
• Retentie van registratie tot run
• Retentie na eerste run

Dit is precies het soort rapport dat een founderteam nodig heeft. Het vereist geen ruwe prompts. Het vereist geen ruwe e-mails. Het vereist geen schrijfrechten op productie.

Het vereist wel het vermogen om productfeiten correct te koppelen.

In één run ontdekte de agent dat een klein aantal actieve externe organisaties het grootste deel van het volume veroorzaakte, dat verschillende betaalde organisaties stil waren geworden en dat recente registratiecohorten een scherpe activatieklif lieten zien, waarschijnlijk veroorzaakt door spamregistraties die de deler opbliezen. Dat zijn de dingen die een founder snel moet zien, niet pas weken later in een dashboardreview.

Een tweede voorbeeld: economie van proefmisbruik

Gemaskeerde productdata is ook nuttig voor vragen die geen klassieke BI-grafieken zijn.

Toen we naar proefmisbruik keken, was de nuttige metric niet het totale verbruikte rekenvermogen. Totale verbruik zou bevooroordeeld zijn richting oudere accounts, omdat die meer tijd hadden om credits te gebruiken. De betere vraag was:

Hoeveel proef-rekenkracht verbruikt een nieuw account in de eerste paar uur na aanmelding?

Met MaskDB mat de agent het rekenverbruik in overeenkomende vensters na registratie. Hij gebruikte creditverbruik uit gebruiksgebeurtenissen, registratietijdstempels uit org-metadata en abonnementsstatus om proef-economie te scheiden van betaald gebruik.

Na het live gaan van de patrouille daalde het gemiddelde proef-rekenverbruik in de eerste uren na aanmelding met meer dan 80%. De zware-verbruikstaart verdween bijna. Op het 90e percentiel daalde het proefverbruik in de eerste uren van ongeveer $4.05 naar ongeveer $0.26, een daling van 94%.

Dat cijfer is niet zomaar een analytics-punt. Het verandert het operationele beeld van het bedrijf. Het laat het founderteam zien dat misbruik niet alleen werd gedetecteerd, maar dat de eenheidseconomie van de proef de goede kant op ging.

En het was mogelijk omdat de database de waarheid bevatte, terwijl de gemaskeerde branch het veilig maakte voor een agent om die waarheid te analyseren.

Een derde voorbeeld: modelkosten in het echte product

Prijspagina's en benchmarksheets zijn nuttig, maar ze beantwoorden niet de vraag waar founders echt om geven:

Wat kost dit model in ons echte product, over echte runs?

Met MaskDB vergeleek de agent historische chatruns door runrecords te koppelen aan het model dat bij de run was geselecteerd en geaggregeerde verbruikte credits uit gebruiksgebeurtenissen.

Dat onderscheid is belangrijk. Je moet historische runs niet toeschrijven aan de huidige standaardmodelprovider van de gebruiker, want standaarden veranderen. Het geselecteerde model bij de run is de bron van de waarheid.

In onze analyse had DS v4 Pro een mediane model-creditkost per chatrun van ongeveer 49% van die van Sonnet. Met andere woorden, de echte mediane chatrun was ongeveer 51% goedkoper op die route.

Ook dit is BI op founder-niveau. Het verbindt productgedrag, infrastructuurkosten en modelstrategie. Het vereist geen nieuw warehouse. Het vereist veilige toegang tot de juiste relationele data.

Dit is geen definitieve vervanging voor een warehouse

Er komt een moment dat een bedrijf een formelere datastack nodig heeft.

Wanneer metrics sterke semantische governance vereisen, wanneer veel teams afhankelijk zijn van dezelfde definities, wanneer historische backfills complex worden, wanneer dashboards onderdeel worden van het operationele systeem, kan een warehouse of lakehouse de juiste keuze zijn.

Maar veel startups grijpen te vroeg naar dat antwoord.

Als je een klein founderteam bent, moet je eerste BI-systeem je helpen vragen te beantwoorden, niet een tweede product creëren om te onderhouden. Een gemaskeerde database kan de brug zijn. Het doet niet alsof datamodellering niet belangrijk is. Het erkent dat de productdatabase al de relaties bevat die je nodig hebt voor de volgende beslissingen.

De agent neemt de noodzaak van oordeelsvorming niet weg. Het maakt de eerste versie van de analyse goedkoper om uit te voeren.

Het patroon voor founderteams

Het patroon is eenvoudig:

1. Behandel de productdatabase als eerste bron van de waarheid.
2. Stel agents nooit bloot aan ruwe productie.
3. Gebruik een productie-achtige branch, geen handmatig samengestelde sample dataset.
4. Maskeer gevoelige kolommen statisch vóór toegang.
5. Behoud ondoorzichtige join-identifiers zodat analyse blijft werken.
6. Stel de branch bloot via een alleen-lezen rol.
7. Laat agents de analyst-loop uitvoeren over de gemaskeerde DB en de omliggende tools.

Dit geeft een founderteam een bruikbaar operationeel systeem zonder eerst een volledig dataplatform te bouwen.

Het zorgt ook voor een schonere beveiligingshouding. De agent heeft een harde grens. De database die hij ziet is al getransformeerd. De rol die hij gebruikt kan niet schrijven. De rapporten die hij produceert kunnen worden beperkt tot gehashte of geaggregeerde identifiers.

Dat is het evenwicht dat we bij VM0 wilden: privacy en veiligheid als basis, niet als afweging, terwijl het founderteam toch veel sneller inzicht krijgt in het bedrijf.

Voordat je een data lake bouwt, vraag je af of een gemaskeerde, alleen-lezen branch van je productdatabase de volgende 20 vragen van je team kan beantwoorden.

Voor ons was dat de snellere weg naar BI.

Bronnen

• Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
• Neon fork van PostgreSQL Anonymizer: https://github.com/neondatabase/postgresql_anonymizer