Blog / Company

Company
July 22, 2026 · 5 min read · Nexus Team

Why we publish shipping notes instead of launch announcements

We publish our roadmap, which is a statement of intent. This week we added the other half: a product updates page, which is a statement of record. One says where we are going. The other says what is already true.

Keeping them separate is the whole point. The standard vendor blur — announcing a capability at the moment work begins on it, then never issuing a correction when the shape changes — leaves buyers unable to tell a shipped feature from an intention, and eventually unable to trust either.

The rules the page runs on

  • Every entry maps to work that is merged and running. No pre-announcements, no "available soon," no entries for things in progress.
  • Dates are the date the work merged, never a future date. We had to go back and fix sixteen blog posts earlier this month that carried publish dates that had not happened yet — the same defect, caught in our own content.
  • Status describes the capability, not the commit. Something merged but still validating on lab hardware is marked as still building, not as live.
  • Every entry that has a meaningful limitation states it, in its own labelled block, on the same page as the good news.
The caveat belongs on the same page as the announcement, or it is not a caveat — it is a footnote you will be quoted against later.

The uncomfortable entries

Some of what is on that page is not flattering. Our new endpoint agent is described as a lab-validated candidate rather than a launch, because that is what it is. A testing pass on scheduled report delivery is listed alongside the gap it uncovered — scheduled runs currently write no audit record — because finding that is the point of testing and hiding it would make the test theatre.

Those entries are the ones that make the page worth reading. A changelog with no bad news in it is marketing with timestamps.

Who this is for

Mostly for MSPs evaluating whether a young platform is worth the risk. That evaluation is not really about the feature list — it is about whether the vendor's description of the feature list can be trusted, because you will be making commitments to your own clients on top of it. A record of what shipped, including the parts that came with caveats, is more useful evidence for that than any individual capability.

Follow the build as it ships.

Nexus is live in our own MSP operations and opening to a limited design-partner cohort. Join the private-preview list.