TypeBox schemas at every boundary
Every route defines its request and response shape as a TypeBox schema. That schema does two jobs at once: it validates incoming data at the edge, rejecting a malformed request before it reaches business logic, and it generates the static types the handler is written against, so the compiler and the runtime agree on what a payload contains.
One definition, two guarantees — that is why we prefer it to hand-written validation sitting beside hand-written types, where the two drift apart the first time someone edits one and forgets the other. A boundary that validates and types itself from a single source is a boundary that stays honest.
One error shape, everywhere
Errors leave the service in one consistent shape, through a single error handler, rather than each route inventing its own. A caller — including a client's own future team — can then handle failures uniformly instead of special-casing the response format of every endpoint. Rate limiting lives at the edge in nginx rather than scattered through route config, so the app has one job and the proxy has another.
Consistency here is not tidiness for its own sake. An unpredictable error surface is where integrations quietly break, because the caller handled the three failures it saw in testing and not the fourth it met in production. One shape means the fourth failure looks like the first three.
Coverage grown, not retrofitted
Tests are written alongside the code, not sprinted at before a release. The failing test comes first, then the code that satisfies it, and coverage is built up as the service grows rather than reconstructed from memory at the end — which never actually catches the cases that matter, only the ones easy to remember.
Our own products run on this pattern. Docusift, Memoria and Lekha share a Fastify backbone, and each reads its runtime configuration from an encrypted per-tenant store through a config module, so where a customer's data lives is set by architecture rather than by a setting. If you need a service built this way, see custom API development.