1.Wie + waar + wat — context-diagram
Het platform in zijn omgeving: drie soorten gebruikers, drie technische lagen, vijf externe afhankelijkheden.
bezoeker)) Klant((Klant met
abonnement)) Johan((Johan
admin)) subgraph VaaS["VaaS-Zorg Platform"] Frontend[Cloudflare Pages
vaas-zorg.nl
~95 pagina's] Worker[Cloudflare Worker
kompas-api
25 endpoints] DB[(Supabase
Postgres + Auth
40+ tabellen)] Frontend --> Worker Worker --> DB end Bezoeker --> Frontend Klant --> Frontend Johan --> Frontend KvK[KvK API
basisprofiel
+ vestigingen] BAG[BAG / PDOK
panden + adressen
+ energielabel] Resend[Resend
email-service
uitgaande mail] Anthropic[Anthropic
Claude API
AI-analyses] DigiMV[DigiMV-data
jaardata
handmatige import] Worker -.haalt op.-> KvK Worker -.haalt op.-> BAG Worker -.verstuurt mail.-> Resend Worker -.AI-analyse.-> Anthropic DigiMV -.import.-> DB
Wat dit diagram u vertelt
VaaS-Zorg is drie technische lagen (Frontend → Worker → Database) plus vijf externe afhankelijkheden. Voor elke afhankelijkheid weet u nu:
- Single point of failure: als KvK API plat ligt, valt vestigingen-functionaliteit uit
- Kosten-bron: KvK + Anthropic kosten geld per call → cache bewaren is essentieel
- AVG-aandacht: data verlaat het platform via Resend (mail) — dat is een verwerker
Strategische implicaties
- Bij outage: kijk eerst welke externe afhankelijkheid faalt
- Bij feature-uitbreiding: weet u meteen welke 5 plekken impact kunnen hebben
- Bij compliance-audit: dit is uw "data-flow" diagram in één oogopslag
2.Het Platform in 9 onderdelen
7 inhoudelijke onderdelen + 2 cross-cutting concerns (Lijm en Skill-fabriek). De Lijm raakt alle 7, daarom apart.
bezoeker)) Klant((Klant met
abonnement)) Johan((Johan
admin)) end Schil[1 Schil
━━━━━━━━━━
Publieke voorkant
vaas-zorg.nl/home] Scan[2 Scan
━━━━━━━
Volwassenheids-
scans] Platform[3 Platform
━━━━━━━━━━
Kompas + bouwstenen
+ instrumenten] Kennisbank[4 Kennisbank
━━━━━━━━━━
Vraagstukken
+ experts] Sectoranalyse[5 Sectoranalyse
━━━━━━━━━━━━
DigiMV-data
+ benchmarks] Mijn[6 Mijn-omgeving
━━━━━━━━━━━
Klant-portal
dossier/voortgang] Beheer[7 Beheer
━━━━━━━
Admin-tools
backlog/autorisaties] Bezoeker --> Schil Bezoeker --> Scan Klant --> Mijn Mijn --> Platform Mijn --> Kennisbank Mijn --> Sectoranalyse Johan --> Beheer subgraph Lijm["8 Lijm — gedeelde infrastructuur"] direction LR Auth[auth.js
magic-link] Gate[access-gate.js
tier-gating] Nav[nav.js
menu] Comp[components/
vaas-map, etc] end subgraph Skills["9 Skill-fabriek"] direction LR Sk1[vaas-klantdossier] Sk2[vaas-pitch] Sk3[vaas-groeipad] SkN[12+ skills] end Schil -.gebruikt.-> Lijm Platform -.gebruikt.-> Lijm Mijn -.gebruikt.-> Lijm Beheer -.gebruikt.-> Lijm Skills -.levert content aan.-> Mijn Skills -.levert content aan.-> Beheer
Wat dit diagram u vertelt
Drie soorten gebruikers komen het platform binnen, elk via een eigen ingang:
- Anonieme bezoekers → Schil (visitekaartje) of Scan (lead-magneet)
- Ingelogde klanten → Mijn-omgeving (hub naar Platform/Kennisbank/Sectoranalyse)
- U als admin → Beheer (uw eigen werkomgeving)
De Lijm zit overal achter — een verandering in auth.js of nav.js raakt elk onderdeel. Daarom is Lijm-werk altijd risicovol en moet altijd op een preview-URL getest worden.
Skills zijn een aparte categorie: ze leveren content (Word, PowerPoint, HTML-widgets) AAN onderdelen, maar zijn zelf geen pagina. Ze leven in Anthropic Skills, niet in deploy-v2/.
Strategische implicaties
- Wilt u snel groeien? → werk aan Schil + Scan (instroom)
- Wilt u retentie verbeteren? → werk aan Mijn-omgeving + Platform (klant-belevenis)
- Wilt u premium-tier verkopen? → Sectoranalyse + Skill-fabriek (waarde voor zware tier)
- Wilt u eigen efficiency? → Beheer (uw werkomgeving versterken)
3.Typische klant-actie: login & scan opslaan
Wat gebeurt er waar wanneer een klant inlogt en een volwassenheidsscan invult? Tijds-volgorde van events.
(login.html) participant Pages as Cloudflare
Pages participant Auth as Supabase
Auth participant API as Worker API
kompas-api participant DB as Supabase DB
scan_sessions participant Resend as Resend
email Klant->>Browser: Open vaas-zorg.nl/login Browser->>Pages: GET login.html Pages-->>Browser: HTML + auth.js Klant->>Browser: Vul email in, klik Login Browser->>Auth: signInWithOtp(email) Auth->>Resend: Verstuur magic-link mail Resend-->>Klant: Mail ontvangen Klant->>Browser: Klik link in mail Browser->>Auth: Verifieer token Auth-->>Browser: JWT toegekend (15 min) Browser->>Browser: Blijft op home.html (sinds 6-mei-2026) Browser->>API: GET /tier (met JWT) API->>DB: Lookup subscription DB-->>API: tier='samen-doen' API-->>Browser: {tier: 'samen-doen', ...} Browser->>Browser: localStorage.setItem('finqdc-tier') Klant->>Browser: Open scan.html en vul in Browser->>API: POST /scans (antwoorden + JWT) API->>DB: INSERT scan_sessions DB-->>API: scan_id API-->>Browser: {success: true, scan_id} Browser->>Browser: Toon resultaat-pagina
Wat dit diagram u vertelt
Een ogenschijnlijk simpele flow als "klant logt in en doet een scan" raakt 5 systemen: Pages (HTML), Supabase Auth (JWT), Worker API, Supabase DB en Resend (mail). Elk systeem moet werken; één onderbreking = klant-fout.
Belangrijk: de tier komt pas binnen NA login. Tot die tijd is localStorage leeg → access-gate denkt "geen tier" → tier-gate (de bekende 'doorgeschoten naar abonnementen'-bug die we vandaag tegenkwamen).
Strategische implicaties
- Performance: 8 round-trips bij eerste scan → caching is belangrijk
- Foutpunten: Resend-bounces = klant kan nooit inloggen → monitor met webhook (al ingericht)
- Mobile-issue: JWT verloopt na 15 min, mobile pauzeert tab → de bekende mobile-token bug
4.Tier-model en toegangsmatrix
Welke tier ziet welk onderdeel? Visueel overzicht van het abonnement-model.
━━━━━━
oriëntatie
presentatie + scan] T1[1 Zelf-doen
━━━━━━━━━
kompas + tools
+ templates] T2[2 Samen-doen
━━━━━━━━━━━
+ kennisbank
+ benchmarks
+ sectoranalyse] T3[3 Samen-doen+
━━━━━━━━━━━━
+ marktpartijen
+ coöperatie] T4[4 Ontzorgd
━━━━━━━━━
volledig
met begeleiding] end subgraph Onderdelen["Toegang per tier"] Schil_O[Schil
publiek
iedereen] Scan_O[Scan
publiek
iedereen] Platform_O[Platform
vanaf Zelf-doen] Kennisbank_O[Kennisbank
vanaf Samen-doen] Sectoranalyse_O[Sectoranalyse
vanaf Samen-doen+] Mijn_O[Mijn-omgeving
vanaf Inzicht] Beheer_O[Beheer
admin-only] end T0 -.kan.-> Schil_O T0 -.kan.-> Scan_O T0 -.kan.-> Mijn_O T1 -.kan.-> Platform_O T2 -.kan.-> Kennisbank_O T3 -.kan.-> Sectoranalyse_O classDef tierStyle fill:#1D3D59,color:#fff,stroke:#0a1f33 classDef onderdeelStyle fill:#73A605,color:#fff,stroke:#3d5a02 class T0,T1,T2,T3,T4 tierStyle class Schil_O,Scan_O,Platform_O,Kennisbank_O,Sectoranalyse_O,Mijn_O,Beheer_O onderdeelStyle
Wat dit diagram u vertelt
Vijf tiers oplopend in waarde — elk hoger tier ontsluit een extra onderdeel. Hogere tiers krijgen ook lagere (Samen-doen+ heeft toegang tot alles wat Zelf-doen heeft).
Het tier-systeem zit technisch in access-gate.js + data-required-tier attributen op pagina's. DEMO_MODE kan dit overrulen voor testbezoekers.
Strategische implicaties
- Funnel-pijn: Schil → Scan is gratis (0). Eerste betaalde stap is
Inzicht→ grote sprong - Upsell-kans: Sectoranalyse vereist Samen-doen+ → premium-feature voor verkoop-gesprek
- Tier-mismatch-bug: als JWT-fetch faalt, valt user terug naar 'geen tier' → tier-gate (vandaag tegengekomen)
5.Deploy-architectuur en code-flow
Hoe komt code van uw laptop naar productie? Welke tools, welke bestanden, welke kanalen?
━━━━━━━━━━
C:\FinQDC - Claude\
FinQDC Kompas\] Mac[Mac mini
━━━━━━━━━━
INACTIEF sinds
2 mei 2026] Laptop -->|git push| GitHub[(GitHub
johan-finqdc/
VaaS-Zorg)] Mac -.geen toegang.-> GitHub Laptop -->|wrangler pages deploy
--branch=main| ProdPages[Cloudflare Pages
vaas-zorg.nl
━━━━━━━━━━
PRODUCTIE] Laptop -->|wrangler pages deploy
--branch=preview| PreviewPages[Cloudflare Pages
preview-URL
━━━━━━━━
tijdelijk] Laptop -->|wrangler deploy
worker/| Worker[Cloudflare Worker
kompas-api
━━━━━━━━━━
EÉN WORKER
voor alles] Laptop -->|Supabase MCP
apply_migration| ProdDB[(Supabase
productie-DB
bwqekgxvfqfilzdfcice)] Laptop -->|Supabase MCP
tests| StagingDB[(Supabase
staging-DB
ozmzppjzvmrccbzrghwt
voor migrations)] Worker -->|service role key| ProdDB Worker -->|alleen voor tests| StagingDB ProdPages -.serveert.-> Bezoeker((Klanten
+ bezoekers)) Bezoeker -->|API-calls| Worker
Wat dit diagram u vertelt
Eindstaat sinds 2 mei 2026: één werkmachine (laptop), één Worker, twee databases (prod + staging-voor-migraties), één productie-domein + dynamische preview-URL's.
Geen apart Pages-staging-project meer — preview-URL's vervangen die rol. Test risicovolle wijzigingen via --branch=preview → unique URL → na verificatie naar --branch=main.
Strategische implicaties
- Deploy-tijd: laptop → productie in < 30 sec
- Risico-isolatie: DB-migrations test eerst op staging-DB voordat productie geraakt wordt
- Recovery: alle code in git → laptop crash herstelbaar via clone
- Geen multi-device-risico: alleen laptop kan deployen → geen race-conditions
6.Pagina-status overzicht (live)
Categorisatie van alle platform-pagina's, automatisch gegenereerd uit scripts/scan-paginas.js. Updates bij elke nieuwe scan.
Wat dit diagram u vertelt
Het cluster-diagram toont per toegangs-categorie hoeveel pagina's er bestaan. Verdacht-vlaggen markeren pagina's met naam-patronen (test/backup/v7+), 0 incoming-links, of >120 dagen ongebruikt — kandidaten voor archief.
Strategische implicaties
- Top-down inzicht: één blik op de balans publiek/lid/admin → zicht op productie-bezetting
- Verdacht-vlag = aandachtspunt: niet automatisch dood, wel candidate voor opruim-batch
- Live: na elke
node scripts/scan-paginas.js+ deploy is dit overzicht actueel — geen handmatig bijhouden - Werktool: voor archiveren ga naar pagina-beheer.html — daar kunt u aanvinken + markdown-lijst exporteren