Nieuwbouwers has one promise: a fair chance at a new-build home for everyone. Dutch municipalities and developers publish their new-build projects on the platform; home seekers register, describe what they're looking for, earn points, and enrol when homes and building plots are released. Allocation runs by lottery or by points — transparent rules instead of who-refreshes-fastest.
Behind that promise sits the software we design, build and operate: a multi-tenant CRM and backoffice with a branded public site per region. Urk, Noordoostpolder, Dronten, Lelystad and Elburg are live today — see urk.nieuwbouwers.nl for what a region looks like.
One codebase, every region its own
Each municipality is an omgeving — an environment with its own subdomain, its own brand colours, logo, menus and pages built from content-block templates. Under the hood it's one Laravel application and one database; on the surface, every region looks and feels like its own product.
Launching a region used to be a project. Now it's a wizard: a background job clones an existing environment — pages with their block structure, villages, news, FAQs, menus, branding and media — rewriting region names along the way. Business data (users, enrolments, payments) deliberately stays behind. For regions migrating from the legacy world, a per-region importer moves 22 categories of data — users, projects, enrolments, payments, point balances — into the new platform.
The public side: from plot map to enrolment
Housing supply follows a hierarchy that matches how new-build actually works: a project has phases (nestable), phases have uitgiftes — release rounds — and a release contains the actual objects: houses and building plots. Home seekers explore them on an interactive Mapbox plot map, follow projects, and get countdowns to the moment a round opens.
Enrolment is where the platform earns its keep. Before anyone can enrol, an eight-step guard chain checks profile completeness, active membership, round status, dates and duplicates. Each round can carry its own custom question set, built with the same form builder the surveys use. Semi-detached homes even handle co-builders: your partner enters an 8-character code and the platform links both enrolments to the paired plots.
- Points, earned honestly. Members collect points by completing surveys and attending project events — attendance is confirmed by scanning a QR code at the venue. Points then decide priority where the municipality chooses a points-based allocation.
- Memberships that renew themselves. Home seekers pay a yearly membership through Mollie; fourteen days before expiry the platform creates the renewal payment and emails a checkout link.
- Allocation on autopilot. For weekly release loops, the platform opens the round on Monday morning, closes it Sunday night, moves enrolled objects to "under option", picks winners by points, and emails winners, losers and the developer — then repeats.
Fair allocation isn't a promise on a landing page here. It's a loop in the code: open the round, close it, award by points, notify everyone, repeat.
The backoffice is the product
Municipality staff and project developers work in a Filament-based backoffice that behaves like a CRM. The dashboard shows the funnel live — environments, projects, release rounds, users, paying members — with an event feed of contact forms, enrolments and payments that refreshes every ten seconds.
Around that core sits everything an operations team needs: project intake and approval flows for developers, a media manager that mirrors the project hierarchy, e-mail templates with full send logs and previews, in-app messaging and correspondence, a survey builder with point rewards, events with QR check-in, CSV and spreadsheet import wizards, and guided onboarding wizards for new organisations. Editors can preview unsaved changes on the real public page before saving. Everything soft-deletes and restores — nothing is ever one click from gone.
Access control runs on roles and rights at three levels — platform-wide, per environment, and per developer organisation — so a developer sees exactly their projects in their regions, nothing else.
Analytics the client can sell
Staff build their own dashboards from a widget library — KPI tiles, meters, bar and line charts on D3 — with drag-and-drop layout, time ranges, cross-chart filtering and persona filters. The interesting part: dashboards can be packaged as Dashboard Products and sold to project developers as a data subscription, tenant-locked and read-only.
Because those dashboards leave the building, privacy is enforced in the query layer: any bucket with fewer than five unique users renders as "not enough data". No accidental re-identification of a home seeker in a small village.
Privacy that survives an audit
The platform handles home seekers' personal data, so the audit trail was designed before the features were. Every change across ~38 models is logged — but the log stores which fields changed, never the values. Logins, failed logins, permission changes, financial-document downloads and impersonation all land in the same trail, tagged by severity, retained two years for normal events and seven for critical ones.
Support staff can log in as a user to reproduce an issue — but impersonation is read-only, banner-marked and logged. Dashboard users get TOTP two-factor authentication. Deletion requests and full database export are built-in screens, not support tickets.
Engineered to last
This is a rebuild: the legacy setup ran a separate database per region behind a GraphQL layer. We replaced it with one Laravel 12 codebase — 73 models, 190 migrations and roughly 3,000 automated tests, including real-browser tests, with query-count regression tests keeping page loads honest. Production discipline is boring on purpose: forward-only migrations, transactional writes, idempotent queue jobs.
And then the AI layer
On top of this foundation we built a full custom AI integration: an AI assistant on every backoffice page, scheduled AI workflows that draft content overnight, and an AI helpdesk for home seekers — all through one guarded gateway that can reach content, never personal data. That story deserves its own page: read the Nieuwbouwers AI case.
FAQ
Can YoTech build a multi-tenant platform like this for us?
Yes — this is exactly the kind of work we do: design, build and run a product end-to-end, white-label under your brand. The pattern fits any vertical where every customer needs their own branded instance on shared code: portals, marketplaces, booking and membership platforms.
How fast can a new environment go live?
A clone wizard copies an existing environment — branding, pages, menus, FAQs and media — in one background job, with names rewritten for the new region. Import wizards and a per-region importer bring in existing data. What used to be a project becomes an afternoon of content work.
Which integrations does the platform run on?
Mollie for payments and membership renewals, Resend for transactional email with full logs and previews, DocuSeal for e-signed agreements, and Mapbox for the interactive plot maps. All of these are swappable — we pick integrations per project, not by habit.
How does it handle GDPR and privacy?
Privacy is structural: the audit trail stores which fields changed, never the values; retention is 2 years for normal events and 7 for critical ones; shared analytics suppress any bucket smaller than five users; and the platform ships two-factor authentication, read-only logged impersonation, deletion requests and database export.
Is there AI in the platform?
Yes — an AI assistant in the backoffice, scheduled AI workflows, and an AI helpdesk for home seekers, all running through one guarded gateway that can only reach content entities, never personal data. We wrote a separate case study about it.
Want a platform like this under your own brand? Plan a call — we design, build and run it, white-label.
