How the Ettex design system holds twenty products together: one accent variable per product, a theme registry of 37 entries, and shared interaction primitives rather than shared screens.
A suite has a problem a single app does not: twenty products have to feel like one thing while each remains recognisably itself. Solve it by making everything identical and the products become indistinguishable; solve it by letting each team choose and you get twenty applications in a trenchcoat. The design system is the answer to that tension, and most of it comes down to deciding what is shared and what is deliberately not.
Colour is the exception that makes the rest work. Each product carries its own accent, applied through a single CSS variable rather than through forked components, so the same button is the product's colour wherever it appears. That one variable does the work people usually attempt with separate component libraries: you always know which product you are in, and nothing had to be duplicated to achieve it. The second deliberate difference is the shape of the main workspace — a grid, a canvas and a document are not the same problem, and pretending otherwise produces a spreadsheet that behaves like a word processor.
Thirty-seven themes sounds like indulgence until you watch somebody with low vision switch to a high-contrast one and keep working. The cost of a theme is low when colour lives in variables; the cost of not having one is that a person stops using the product.
The result is a suite where moving from a document to a spreadsheet to a board feels continuous, without the products losing their identity. Ettex Docs and the rest share the primitives and the themes; what they do not share is the workspace itself, because that is the part that should differ.
The registry holds 37 entries, including light, dark, sepia and several high-contrast and developer-familiar palettes.
Through a single accent variable set per product, which the shared components read. No component is forked to change colour.
Only when it is enforced as policy. When the shared primitive is genuinely easier to use than rebuilding one, people reach for it without being told.
An OpenAPI document turns your API into something tools can consume — generating clients, powering try-it consoles, and catching the drift between what the docs claim and what the API does.
REST is a set of constraints, not a specification, which is why every API claiming to be RESTful is different. The conventions worth following are the ones that let a developer guess correctly.
Nobody reads API documentation from the top. They search for the endpoint, copy the example, and leave — which tells you exactly what to spend your effort on.