Secrets do not belong in the browser

Passwords, API keys and tokens are never embedded in the website. They remain on a protected server and are used only after the requester has been verified.

Access is separated per client

Every client can see only their own data. This is not merely a user-interface choice; it is enforced at database level so the boundary remains effective when someone tries to bypass the screen.

An extra lock on the door

Two-step verification is available for stronger account protection. The entire site enforces secure connections and applies restrictive browser security policies.

Security is not a one-off project but a habit. Establishing a sound foundation costs relatively little; recovering from an incident costs much more in both money and trust.

Curious how mature and secure your data approach is? Try the data maturity scan on this site.

Why you want this too

One incorrect change published directly to production can take a website offline or show incorrect figures to a client. An intermediate stage lets you test calmly, demonstrate the result and only then publish it—with a clear recovery path if something goes wrong.

Pragmatic, not heavy

We established four environments: a preview for each change, a technical test environment, an acceptance environment that resembles production and the live site. This did not require expensive tooling; it used the capabilities already available. The setup took a few hours and has since prevented mistakes that would have cost much more time.

The same applies to reporting. A dashboard that reaches management without a control step is a risk. A small review before production quickly pays for itself.

Simple

We chose a static website without a heavy framework. The result is fast, requires little maintenance and avoids a constant stream of technical updates. Fewer moving parts means fewer things can break.

Secure

Our golden rule is that secrets never belong in the browser. Sensitive connections to bookkeeping and email services run through a protected server layer that first checks who is making the request. Client data is separated per client and two-step verification is available.

Scalable

The database and storage can grow from one client to a hundred. Because each part has a clear boundary, we can replace or extend components later without rebuilding everything.

The same balance—simple where possible and robust where necessary—makes the difference in every data project. Building too much is as risky as building too little.

Qnext wanted something better: one secure place where every client can find their own dashboards, invoices and documents. The question was whether to buy or build.

Buying seemed logical, but…

Ready-made client portals exist, but they are often expensive and generic. They can also create vendor lock-in. A small specialist business then pays for dozens of features it never uses.

Why we chose to build

With the right modern choices, a dedicated platform is surprisingly achievable without a large development team. We chose a lean stack that remains under our control, has low fixed costs and does exactly what our clients need.

The most important benefit is not the technology itself but the signal it sends: we apply what we advise. Data-driven, structured and secure.

In the next parts of this series, we explain the choices we made and what they can teach you about your own data and reporting processes.