Why we call modules "design-partner ready" instead of "coming soon"

For a while, this site described nearly every module the same way: "in development," with a form to leave your email for when there was "something to see." That was a safe, defensible thing to write. It was also, by the time we'd actually shipped tenant isolation, signed endpoint execution, live patch deployment, a working CRM pipeline, and a compliance posture engine we run our own practice on, no longer an accurate one.

A blanket "in development" label undersold the platform in a specific way: it couldn't distinguish a module we dogfood daily in our own MSP operations from one that's still a design sketch. Both looked identical to a visitor. That is a status-honesty problem in the opposite direction from vaporware — instead of claiming more maturity than we had, we were claiming less, which is a smaller sin but still not the goal.

The fix

• Every module now carries one of four honest labels — live in our own practice, available now on configure, actively building, or on the roadmap — instead of one blanket status.
• The call to action changed to match: Nexus runs our own MSP operations today, and what we're opening up is a limited design-partner cohort, not a "notify me when it exists" waitlist for something that already exists.
• The roadmap page still tracks the same four build phases — Foundation, Core modules, Private beta, General availability — so "design-partner ready" has a specific meaning: the core modules phase, with real workloads, not GA polish.

We caught this the way we'd want a customer to catch it: an outside review of the public site, read literally, line by line, against what the platform actually does today. That is exactly the kind of feedback loop we want the design-partner cohort itself to create once it's running — real usage surfacing the gap between what we say and what's true, on a tighter cycle than we'd find it ourselves.