HumanHours demo-account voor prospect (Michael Burian / NDI)

Datum: 2026-05-16 Status: design, goedgekeurd door Ralf — wacht op spec-review Type: data-seed taak, GEEN app-wijziging

Doel

Een geloofwaardig demo-account in HumanHours-productie zodat Michael Burian (NDI) kan zien hoe het product nu werkt. Alles uit de sales-call (AI-kosten per transactie, onderzoeksagent, trust-/bronlagen, agency-tree) is toekomst-roadmap en valt buiten scope.

Gesanctioneerde uitzondering op de prod-data regel

De staande regel "nooit demo-data in prod" (memory feedback_no_demo_data_in_prod) is op 2026-05-16 door Ralf bewust overruled voor dit ene account, nadat het conflict en de letterlijke sterkte van de regel (incl. de al-afgewezen "(Demo)"-tag en "ruim later op"-mitigaties) expliciet aan hem zijn voorgelegd. De uitzondering is in memory vastgelegd; de absolute regel blijft voor al het andere staan.

Scope

In scope (alleen bestaande velden/tabellen):

Auth-user ralf+demo@triad.nl (beheerd door Ralf), aangemaakt zonder confirmation-mail.
organizations rij: duidelijke "(Demo)"-naam, plan = 'pro', geen Stripe-velden, default uurtarief/valuta standaard (EUR / €45).
org_members: de demo-user als owner.
Eén API-key voor de demo-org (via het bestaande key-mechanisme, niet handmatig gehackte hash).
Eén multichannel front-office chatbot-agent.
~90 dagen events over bestaande, reeds geseede task_types, realistische niet-ronde volumes, ge-POST via de echte ingest-API zodat de app zelf de besparing in uren + geld oprolt naar aggregates.

Buiten scope:

Geen code-, schema- of feature-wijziging aan de app.
Geen org_invites van onze kant — Ralf nodigt Michael later handmatig als viewer uit via de UI.
Geen Stripe/billing objecten. Geen trust-/bronlaag, geen agency-tree, geen meerdere agents.

Aanpak

Gekozen: A — seed via de echte ingest-API. Events worden ingeschoten zoals een echte integratie (n8n/make/webhook) dat doet; de productie-app berekent hours_saved / cost_saved zelf. Meest getrouw aan "hoe het nu werkt", nul app-wijziging. (Alternatief B, directe SQL in events/aggregates, is verworpen: fragieler en risico op cijfers die niet matchen met de echte logica.)

Org + member + API-key worden via directe DB-inserts / Supabase CLI gezet (die lopen niet via de events-API).

Teardown

Alles hangt aan één org_id. Opruimen = die org cascade-deleten + de auth-user ralf+demo@triad.nl verwijderen. Niets buiten die org wordt aangeraakt.

Open punten voor het implementatieplan

Deze moeten in het plan worden opgelost (deels input van Ralf nodig):

Supabase-toegang. Project esekswemujghuuagiwwt is alleen via de Supabase CLI bereikbaar (niet via MCP), repo is lokaal nog niet gelinkt. Nodig: supabase link + DB-connection / SUPABASE_SERVICE_ROLE_KEY + project-URL. Bron: Vercel-env van project humanhours, of Ralf levert ze aan.
Auth-user aanmaken zonder confirmation-mail (Auth admin API, email_confirm=true, bekend wachtwoord dat aan Ralf wordt teruggegeven).
API-key minten conform het bestaande mechanisme (API_KEY_PEPPER → hashing); de exacte generatie-/opslagweg in packages verifiëren.
Ingest-endpoint + payload. De live ingest-URL (humanhours.dev) en het exacte event-schema (required fields) verifiëren tegen apps/web / SDK.
Rollup. Hoe events → aggregates wordt opgerold (cron/trigger) en hoe we dat triggeren/afwachten zodat de demo-cijfers kloppen vóór Michael kijkt.
Demo-scenario-detail. Concrete task-type mix, volumecurve over 90 dagen en resulterende besparings-orde-van-grootte (geloofwaardig, niet te mooi).

Succescriterium

Ralf kan inloggen als ralf+demo@triad.nl, ziet een geloofwaardig dashboard met ~90 dagen besparing in uren + geld voor één front-office chatbot-agent, en kan Michael daarna handmatig als viewer uitnodigen. Nul wijziging aan de app; alle demo-data is met één org-delete te verwijderen.