Domior: A Config-Driven Question Flow for Property Site

Building the questionnaire the whole product runs on.

Most property sites hand you a search box and a few thousand listings. Domior works the other way round. It asks a long set of questions first and narrows the market down from the answers, so the questionnaire is the foundation everything else sits on.

It runs to dozens of questions, and the client expected to keep changing it as they learned what worked: reordering them, rewording them, adding new ones. Written into the frontend, every one of those changes would have needed a release from me.

I came in as lead frontend architect.

Rather than building the screens, I built the thing that renders them. The backend sends a

configuration document and the frontend turns it into an experience.

Screens come from config. Screen patterns and input widgets resolve through lookup tables. A new kind of question is a config change on the backend plus, if the pattern is new, one line in a registry.

The backend owns navigation. The frontend moves to the screen the backend names and never works out the next one itself, so questions can be reordered server-side without putting the client out of step.

Adding a language is a content change. The frontend keeps no locale list of its own. Routing, the language switcher, page metadata and the sitemap all read the registry that ships with the translations.

Underneath, the config layer and the state model are pure: no React, no I/O, no side effects, with all request sequencing in one place. That keeps the parts most likely to break testable as plain functions instead of through a rendered UI.

I built on the client's mandated stack and enforced a strict internal structure on top of it.

Framework: Next.js 16.2 (App Router) with React 19.2, fully typed in TypeScript 5

Styling: Tailwind CSS v4 over a token layer extracted from Figma

Data layer: TanStack Query v5 with typed services per endpoint and retries limited to transient failures

Forms: React Hook Form with Zod schemas derived per screen from the backend config

Internationalization: next-intl across three locales with parity checks in CI

Security: the session token is held in memory and never written to storage

Quality: Vitest across pure and DOM projects, a combined lint, typecheck, test and build gate, plus Husky hooks

The founder owned the product, the API and the database, and the designs came from a designer in Figma. I owned the frontend. The relationship was flat: decisions happened in conversation, and either side could talk the other out of something.

That left room to contribute outside my own scope. I gave input on branding and UX, raised flows that were going to confuse people before they got built, and brought the outside perspective of someone who has built and advised on products for twenty years. None of it was my call to make, and it didn't need to be.

Bruno César, Domior