One design system, twenty products, 1,275 screens

We just shipped twenty products. Six full applications, eight focused kits, six component packs. Counted honestly, that is 1,275 screens, layouts, templates and components.

The obvious way to build that is to write 1,275 files. That way is also how you end up with a button that looks slightly different on every page, and a homepage number nobody can check. Here is what we did instead.

The screens are built from parts, not written one by one

There is one foundation: a set of tokens plus the primitives, layouts and patterns everything else is made from. Every product is assembled from it. A dashboard in the analytics app and a settings page in the CRM use the same card, the same table, the same field, reading the same tokens.

"A part you learn in one product is the same part in the next" is not a slogan. It is just what happens when there is exactly one of each.

Nothing hard-codes a colour

Each product sets two or three variables for its accent and inherits the rest. No screen contains a colour code. The payoff is concrete: you restyle a whole product from one file, and we prove it by re-tinting every demo with its own accent.

If a single screen had hard-coded its blue, that promise would break on that screen, and you would find it at the worst moment.

The demo is the product

Every product has a live demo that runs the exact source you download, driven by the product's own list of screens. That is a forcing function, not a marketing choice. If a screen is missing from the demo, it is missing from the download, because they read the same list.

The usual way a template shop drifts into dishonesty, where the sales page promises more than the zip contains, is structurally impossible here.

A script counts the claims, and the build believes it, not us

Every number on the storefront is counted against what is actually on disk by a script that fails if anything is overstated. It also writes the table the store reads, so a product becomes buyable the moment its screens exist, and stops the moment somebody raises the number past them. Nobody flips a switch.

A check you have never seen fail is not a check.

The first version of that script had a line-ending bug that made it read zero files and cheerfully report a clean pass. That is exactly the failure it exists to prevent, so it now refuses to pass on an empty read. The lesson generalises further than we would like.

What it bought us

Consistency that survives scale, a homepage number that is true by construction, and a codebase where adding the twenty-first product is assembly rather than a new project. The cost is up front: the foundation has to be genuinely good before the first product is worth building on it. That trade is the whole game.