Building in the open: why we publish our own roadmap and test-to-code ratio instead of a glossy one-pager

A glossy sales one-pager has one job: make the product look finished. It lists capabilities as bullet points with no dates, no status, and no way for a reader to tell "shipped and battle-tested" apart from "on the whiteboard last quarter." That's not necessarily dishonest — it's just a format that was never designed to be checked against reality, and most readers know that going in, which is exactly why it persuades less than it used to.

We publish a build-phase roadmap instead, with the same four stages every time — Foundation, Core modules, Private beta, General availability — and a plain answer for where each module of the platform sits inside them. We also publish an automatically-computed test-to-production ratio on the project README, not a hand-picked "we're thoroughly tested" claim.

Why we think the checkable version is the more persuasive one

• A roadmap with dates and phases can be wrong in public, and being caught wrong in public is a real cost to us — which is exactly the incentive a one-pager doesn't create for whoever wrote it.
• A test ratio generated automatically from the codebase can't be quietly inflated for one blog post and left stale everywhere else — the same script runs against every change, so the number you read is the number as of today, not as of whenever it was last convenient to compute it.
• Specificity is falsifiable, and falsifiable claims are the only kind worth trusting from a vendor you haven't worked with yet. "Enterprise-grade" cannot be checked. "10.8k lines of dedicated test code, computed from the repository, gating every merge" can be.
• It also disciplines us internally — a module doesn't get to move to the next roadmap phase because a demo looked convincing to a prospective design partner. It moves when the underlying wiring and the tests behind it actually justify the label, because the label is public and someone will eventually check it against the code.

A glossy one-pager describes a product. A public roadmap and a real test ratio describe a product's relationship to the truth — and that relationship is the thing you're actually betting on when you pick a vendor to run your operations on.

This isn't a claim that transparency alone makes a product good — a beautifully documented, honestly-labeled product that's still thin underneath is still thin. What we think it buys is a faster, harder-to-fake feedback loop: if a status label is wrong, an outside reader who checks the platform page against what we said can catch it, the same way an internal review caught our own "in development" label undershooting where the platform actually stood a few weeks ago. We'd rather be caught wrong quickly and correct the label than be believed for longer on a claim we couldn't back up.

The roadmap page and the README dashboard are both live right now, not a promise to build them later — read them the same skeptical way you'd read this post, and if a number or a status looks off, that's worth telling us directly.