Productdocument (PRD)
Status: levend document. Laatst bijgewerkt: augustus 2026.
Probleem
Section titled “Probleem”Ik lever websites aan klanten. Elke site is functioneel vergelijkbaar (home, over ons, diensten, nieuws, referenties, contact) maar heeft een eigen huisstijl en een eigen paginaopbouw. Nu betekent elke nieuwe klant een nieuw project opzetten, een CMS kiezen of bouwen, en handmatig deployen. Dat schaalt niet, en onderhoud loopt uiteen zodra sites gaan divergeren.
Oplossing in één zin
Section titled “Oplossing in één zin”Eén gedeelde codebase en blokkenbibliotheek, waaruit per klant een eigen site wordt samengesteld met eigen huisstijl, eigen content en een eigen deployment — beheerd vanuit een centraal dashboard.
Gebruikers
Section titled “Gebruikers”| Rol | Wie | Wat die doet |
|---|---|---|
| Platformbeheerder | Ik | Klanten aanmaken, sites uitrollen, domeinen koppelen, alles monitoren |
| Klantbeheerder | Contactpersoon bij de klant | Content beheren in het CMS van de eigen site |
| Bezoeker | Publiek | De site bekijken, contactformulier invullen |
Kernprincipes
Section titled “Kernprincipes”- Techniek is gedeeld, verschijning is per klant. Dezelfde applicatiecode en dezelfde blokken; huisstijl en paginaopbouw komen uit de database van de tenant.
- Een pagina is een geordende reeks blokken. Geen vaste velden per paginatype. Dit is de aanname waar de latere pagebuilder volledig op leunt.
- Isolatie per klant. Eigen deployment, eigen database, eigen domein. Een probleem bij één klant raakt de anderen niet.
- Update één keer, uitrollen naar allen. Een verbetering aan het template komt bij alle klanten terecht zonder handwerk per site.
- Klein beginnen. Handmatig doen wat nog niet vaak genoeg gebeurt om automatisering te rechtvaardigen.
Scope MVP (fase 1)
Section titled “Scope MVP (fase 1)”Eén werkende, verkoopbare klantsite:
- Publieke pagina’s: home, over ons, dienstenoverzicht, dienstdetail, nieuwsoverzicht, nieuwsdetail, referenties, contact.
- Contactformulier met opslag van inzendingen en e-mailnotificatie.
- Eigen CMS op het
admin-subdomein: inloggen, content beheren (pagina’s, diensten, nieuws, referenties, navigatie, instellingen), media uploaden. - Huisstijl per tenant via design tokens uit de database.
- Content opgeslagen als gevalideerde block-JSON.
- SEO-basis: meta-tags, sitemap, robots, Open Graph.
- Handmatig gedeployed op Coolify.
Succescriterium: ik kan deze site aan een echte klant opleveren en die klant kan er zelfstandig content in beheren.
Buiten scope voor de MVP
Section titled “Buiten scope voor de MVP”- Master dashboard en geautomatiseerde provisioning (fase 2)
- Pagebuilder met drag-and-drop (fase 3)
- Analytics en activiteitenweergave (fase 4)
- Meertaligheid
- E-commerce
- Rollen fijnmaziger dan beheerder/redacteur
- Contentversiebeheer en revisies
Roadmap
Section titled “Roadmap”| Fase | Inhoud | Doel |
|---|---|---|
| 0 | Monorepo, documentatie, agent-regels | Fundament waar Cursor efficiënt op kan bouwen |
| 1 | Site-template + eigen CMS, één tenant | Eén verkoopbare site |
| 2 | Master dashboard + provisioning via Coolify API + custom domains via Cloudflare for SaaS | Nieuwe klant van 0 naar preview-URL in minder dan 5 minuten |
| 3 | Pagebuilder (Puck) bovenop het bestaande blokmodel | Klant bouwt zelf pagina’s |
| 4 | Analytics (Umami), activiteitenlog, uitbreidingen | Inzicht en doorgroei |
Openstaande productvragen
Section titled “Openstaande productvragen”- Krijgt de klant toegang tot de pagebuilder, of alleen tot content binnen bestaande pagina’s?
- Wie beheert de huisstijl — ik bij oplevering, of de klant zelf?
- Hoe gaan we om met klantverzoeken die een uniek blok vereisen? Wordt dat blok generiek en onderdeel van de bibliotheek, of komt er een mechanisme voor tenant-specifieke blokken?
- Wat is het onderhoudsmodel richting de klant (abonnement, strippenkaart, niets)?