# Case belderbrandt.nl | Observability Architect

> How a mortgage adviser without an ops team sees in thirty seconds whether booking and contact work. Error monitoring, privacy and performance from day one.

https://observability-architect.nl/en/cases/belderbrandt/ · English

Published on 13 September 2026 · Patrick Ditmar

**Belderbrandt: observability for a website where every appointment counts**

Belderbrandt Hypotheek Tilburg is an independent mortgage adviser. In 2026 the practice got a new, bilingual website with one goal: getting visitors to book an advisory appointment. We built the observability in from day one, instead of after the fact. The site is at https://www.belderbrandt.nl

## The situation

A small site, a large stake. The website is the front door of the practice: a booked appointment is the conversion, and the planner relies on an external calendar. There is no ops team watching dashboards. So the question was not "how do we collect as much data as possible" but "how does one person know within thirty seconds whether booking and contact work, and does he hear about it when they do not".

## What we did

### Observability Audit: the questions first, then the signals

We started with the two business flows: booking and getting in touch. From those followed which signals matter: does a request succeed, how long does it take, and does it fail in a way the visitor does not see. The standard measurements turned out to say nothing about that: a failed submission politely got a friendly response and thereby vanished from every error statistic. That was the first finding, and immediately the most important one.

### Tooling & Implementation: one switchboard, three runtimes, no personal data

Error monitoring and tracing across browser, server and edge, driven from one configuration, so a signal is switched on or off in one place and the privacy policy cannot differ per runtime. Personal data is not collected; a second scrubbing layer catches what would still travel along in a URL. Every caught error in the booking and contact flow becomes a structured failure signal with operation, category and upstream status, never with form data. Test environments and local development send nothing to production. Session recordings are deliberately off: they cost measurable load performance and answered no question.

### Performance Engineering: measuring what the visitor experiences

Measurements from real visitors next to lab measurements, with performance budgets in the pipeline as change detectors. An investigation into the gap between mobile and desktop showed that the measured gap came entirely from the measurement preset and not from the site. Along the way it did find a real defect, a lazily loaded hero image, which was fixed immediately. The planner got its first availability delivered inside the page itself, so the visitor does not wait for the external calendar.

### Strategy & Enablement: from data to one glance

One dashboard with the business flows at the top: volume, speed and failure signals, below that web vitals per page, errors and releases. Alerts as a safety net: an uptime monitor on the availability route and one notification per failure signal in production. Automatic weekly and monthly reports record a snapshot, so trends survive beyond the platform's retention period. Every decision is written down in a decision record, with the measurements that support it.

## What it delivers

- An outage in the booking or contact flow is visible before a customer asks about it.
- Every change to the site is measurable: performance in the pipeline, errors per release.
- Privacy is a design decision, not a setting applied afterwards.
- The practice needs no ops team: one glance, one safety net, one report a week.

## Three lessons

1. Status codes do not tell everything. An error that is handled gracefully is invisible to standard monitoring; make failure signals explicit.
2. Measure the measuring instrument. A gap between mobile and desktop can come from the measurement preset; check that before you start optimising.
3. Fewer signals, better chosen. Every signal that is on costs load time or attention; turn on only what answers a question.

## Sound familiar?

Even without an ops team, your site can tell you whether it works. Book a free strategy call.

- Book a call: https://calendly.com/patrick-pdict/30min
- Send mail: patrick@pdict.eu