One build, five hosts
The www site and four product hosts are staged from the same static export. A public host receives only public pages: signed-in screens are removed from its upload, not hidden behind a rule.
Case study · Magnolia BluePrint
Five sites from one build, with every claim on record.
We built magnoliasystems.ai, the Magnolia Haven site and the Magnolia FieldSense pages as one codebase. One static build is staged for five hosts, every public claim is recorded with its evidence, and the whole test suite runs before anything is published.
IRIS (Integrated Reasoning & Intelligence Steward) is our planning assistant. The scoping page saves your answers to your own computer as a file, then offers a link to email them to us.
The problem
Sites that nothing could check.
Each product needed a public site, and every site makes claims: what a product does, what is built, what stays private. The product hosts had been published once by an older release pipeline and left untouched. Nothing in our main repository could update them, test them or hold them to what they said.
Copy also drifts faster than code. A sentence nobody can trace to evidence is a sentence nobody can check, and a sign-in screen published to a public host is a screen anyone can download.
What we built
One codebase, one register, one way to publish.
A register for every claim
Each public claim has an entry saying what it claims, which product it is about, whether it is built, and a file or ticket a reviewer can open. A product's claims must all be built before it opens for sale.
Pages that say what they know
A measured figure says when it was measured, and a test holds it to its evidence. Pages meant to stay private are left out of the sitemap and marked not to be indexed.
Screens held to the design
The Magnolia Synergy screens are checked against the design team's package for structure, routes, components and accessibility, and their stylesheet must match the package byte for byte.
How we built it
Checked on every change, published on purpose.
- 01
Every change runs the suite
Lint, formatting and the site's own tests run on every proposed change, beside the repository's gate suite, and again before the change joins the main line.
- 02
Publishing is its own approved step
A publish names the approval behind it. Left at its default, the publish workflow builds and checks the bundle and uploads nothing.
- 03
The bundle is checked before upload
The built pages are scanned for tracking tags, and the application screens are removed from public hosts, before anything leaves the build.
The result
What the sites look like on the record.
- Hosts from one build
- 5
- The www site and four product hosts, each staged from the same static export with its own rules.
- Pages in the sitemap
- 29
- Every page meant to be found. Sign-in screens and private pages are left out on purpose.
- Claims on record
- 115
- Each with its product, whether it is built, and evidence a reviewer can open.
- Automated test cases
- 1,229
- In 116 test files, run on every proposed change and before every publish.
- Pull requests merged
- 170
- Into the sites' code since it moved into our main repository on 28 August 2026.
Measured 6 October 2026, from our main engineering repository as it stood that day.
Tell us what you need built.
Describe your systems, your reports and where the time goes on the IRIS scoping page. You keep a copy, and an engineer reads it before we talk.