Build once, deploy to many: how MAD runs its code

A small team running many products has one enemy: drift. Every app built a little differently is an app that breaks differently. Our answer is a rule we call singularity and parity: there is one way to do each thing, and every app does it that way.

Singularity: one of each

• One server runs every product, each in its own container.
• One deploy script ships every app: it mirrors the code, records the commit, builds, and swaps the running app only if the build passed.
• One sign-in, one cache, one mail server, one backup routine, one web front with one security policy.
• One version and release-notes rule: an app whose code changed cannot ship under its old version number.

Parity: build once, everyone gets it

When we improve something, every app gets it. The help drawer that slides in from the right edge went into every app the same week. The shared app frame, with its menus, its drawers and the Ndebele strip, is one file synced into each app. A fix to the family tree's printing reached the book PDF and the screen at the same time.

If two apps do the same job two ways, one of them is wrong.

Every change checked, every change reversible

Every change to a live server is backed up first, checked before it is used, and put back by itself if any site answers differently afterwards. Scripts are read whole before they run, so a change made while one runs can never half-apply. And everything is pushed to source control the moment it is committed.

Why it matters

This is how a handful of people run a clinic, a shop, a family platform, a library and an AI desk without a large operations team: the discipline is in the system, not in anyone's memory.