Maas & Waal Makelaardij

A brokerage website looks simple from the outside. Some homes, some team photos, a contact form, a few pages about selling and buying. Fair enough.

But that is not really the job.

People arrive on a site like this with something big on their mind. Selling a house. Buying one. Figuring out what their home is worth. Wondering who to trust with a very expensive, very emotional decision.

So the website had to do more than look nice. It had to make Maas & Waal feel like Maas & Waal: warm, direct, local, approachable. And underneath that, it had to work like a proper modern platform.

Listings. Lead flows. Realworks. Supabase. Tina CMS. Reviews. Blog content. Landing pages. Metadata. Forms. Filters. The lot.

The strongest thing about Maas & Waal Makelaardij is not a feature.

It is Maurice and Cornelie.

The site needed to make that obvious quickly. No faceless agency energy. No generic real estate gloss. No "premium full-service housing solutions" nonsense. Just a clear, confident website for real people helping other real people move.

That shaped the whole experience.

The navigation became focused around the things visitors actually came to do: view listings, sell a house, buy a house, request a valuation, get in touch. The homepage pushes people into those paths without making everything feel like a hard sell.

Because that balance matters here.

Buying or selling a house already has enough pressure in it. The site needed to guide, not shout.

The public site needed to feel simple.

But simple for the visitor does not mean simple underneath.

There are basically two lanes running through the whole thing. Listings come in from Realworks, get shaped into a stable public website model, and end up as listing pages, detail routes, images, filters, metadata and share links.

Leads go the other way. A visitor starts with something human: a valuation request, a viewing question, a contact form, a specific house. The site turns that into a structured handoff for Realworks CRM, with the right intent, person details and property context attached.

That is the trick.

Keep the front end light. Keep the business flow intact. Do not create a second admin job for the team.

Listings inLeads outRealworks flow

One lane brings Realworks listings into a stable public website model. The other turns warm human contact into clean CRM handoffs without creating a second admin flow.

Calm on the surface, structured underneath

Listings in

Realworks stays the upstream source. The public site reads a calmer model that has already been fetched, shaped, and stored separately.

External source

Raw listing changes, media, and status updates enter from the external platform.

ListingsMediaStatus updates

Stability layer

A server layer fetches what matters, stores it separately, and gives the frontend one stable model to work with.

Server fetchSeparate databaseStable site model

Public outputs

Public pages, filters, metadata and share images stay fast and consistent because they read the shaped site model instead of the upstream feed directly.

ListingsDetail pagesSEO + share

Leads out

The site keeps contact paths light and human on the front end, then turns them into clean CRM handoffs once the visitor acts.

Website funnels

Valuation requests, direct contact, and property-specific intent all begin inside the website experience.

ValuationContactViewing request

Structured handoff

Each submission is normalized into one cleaner payload with the lead type, person details, and any property context attached.

IntentProperty contextContact details

Operational home

The lead lands where the team already works, so the polished public layer does not become another admin system.

Mapped lead typeDirect CRM deliveryNo second admin flow

The listings section is where a lot of broker websites quietly give up.

They either send people straight to a property portal, show a static grid, or treat the listings page like a decorative extra. This needed to be more useful than that.

So the listings flow is backed by Realworks data synced through Supabase public views. The site maps that raw listing data into clean public cards and detail pages: address, status, price, surface area, rooms, bedrooms, energy label, media, share images, and all the bits people expect to see without thinking about where they came from.

It also handles the awkward real estate states. Available. Sold under reservation. Sold. Prospect listings. Public detail pages. Teasers. Missing data. Media renditions. Slugs. Sitemap entries.

All the stuff that only looks simple when it works.

The overview also got proper filters. City, budget, living area, rooms, bedrooms, property type, status, energy label. Server-side, URL-based, shareable, and tied to the same Realworks/Supabase source as the rest of the site.

No fake filter UI sitting on top of stale data.

The forms are not just forms.

They are the business end of the website.

A visitor can ask a general question, request a valuation, ask about a specific house, start with buying guidance, request a callback, or register interest as a searcher. The form adapts to that context instead of pretending every lead is the same lead.

On listing detail pages, the form carries the property context with it. So when someone asks about a house, the system knows which house.

Under the hood, submissions go server-side into Realworks. Credentials stay off the browser. The route creates the relation, creates the response, records an audit trail in Supabase, and keeps visitor-facing errors clean instead of leaking operational details.

There is also optional Resend notification handling for client emails, visitor confirmations, and private failure alerts.

The boring grown-up stuff.

Which is usually the stuff that matters most once real people start sending real phone numbers.

Where the flows show up

Homepage, listings, valuation, service, contact, and mobile moments from the live flow.

The first screen needed to make the new agency feel personal from day one, with the people and valuation route visible immediately.

Listings read from the shaped public site model, so filters, cards, metadata, and detail routes stay fast and consistent.

The primary valuation CTA stays important and reachable without turning the whole site into one big conversion siren.

The team page keeps Maurice and Cornelie visible without drifting into generic real estate gloss.

Service content gives visitors enough guidance to choose a path without turning the page into a heavy sales funnel.

Contact moments stay simple on the surface, while the lead flow still reaches Realworks with mapped intent and context attached.

The mobile flow keeps the same warm first impression while still routing visitors quickly toward valuation, listings, and contact.

The listing experience still needs to scan cleanly when visitors are browsing homes on a phone.

Mobile contact stays close to the workflow, because real leads often start with a quick question from a phone.

The editorial side runs through Tina CMS.

That means Maas & Waal can manage the parts that should actually be editable: page copy, service content, team content, reviews, partners, blog posts, landing pages, and site settings.

But listings stay out of the CMS, because listings are not editorial content. They belong in the Realworks flow.

That split is important. It keeps the content model simple for humans, and keeps production listing data where it belongs.

A lot of CMS work goes wrong when everything becomes editable just because it can. This went the other way. Editable where useful. Controlled where necessary.

There is a lot of small product work in a site like this.

The primary valuation CTA got treated that way too. "Curious what your home is worth?" is important, but it should not shout over the whole page. So it starts in the hero, then quietly moves into the navigation once the hero button scrolls out of view. Same action, still reachable, without turning the site into one big conversion siren.

The hero needs to feel warm without turning into a stock-photo brochure. The team section needs to build trust without becoming sentimental. The service pages need enough explanation to help people choose, but not so much that they feel trapped in a sales funnel.

The listing cards need to scan quickly. The detail pages need to feel rich without overwhelming people. The contact moments need to stay close to the workflow. The metadata needs to hold up when Google, social crawlers, and shared links touch the site.

So in short: Next.js 16 App Router, React 19, TypeScript, Tailwind CSS, Framer Motion, Tina CMS page documents, Realworks listing sync, Supabase public views, listing presenters, server-side listing filters, dynamic detail routes, prospect listing handling, Realworks lead submission, Supabase audit rows, Resend notification hooks, structured metadata, sitemap alignment, review rendering, landing pages, blog content, consent-aware analytics, Vitest coverage, and enough edge-case work around houses, forms and crawlers to keep it honest.

No big deal.

In the end, that was the job.

Make a local brokerage feel trustworthy online.

Make a real business workflow feel simple.

Make the website do the invisible work, while Maas & Waal still sounds like Maas & Waal.