The Sprawl

In the last post, I said Cadres was now a suite. I thought that was the end of the story.

It was not. I kept building. This post is the honest account of where that went, and the rule that stops it from becoming a problem.

The Service Desk Wanted Out

The service desk started life inside the endpoint platform. That made sense at the time. Tickets about servers, raised next to the servers.

Then I started using it properly and the seams showed. A service desk has its own gravity. It needs SLA policies that do real calendar math, per customer, per priority, in the customer’s timezone. It needs intake where people already are, which today means Teams and Slack, not a portal bookmark. It needs change governance with a CAB and freeze windows. None of that has anything to do with patching a server.

So the service desk became its own product. It is called Beacon.

The part I care about most is what happened to the connection. Beacon and the endpoint platform now talk over a bridge: incidents and asset state flow one way, ticket status flows back, and a technician can run a device remediation from the ticket through a fixed set of allowed verbs. No free-form scripts over the wire. The bridge is explicit, optional, and inert if you never configure it. If you run Beacon against someone else’s endpoint tooling, or someone else’s ITSM against our endpoints, both work.

That last sentence took real discipline to make true. It matters later in this post.

The Network Was Next

Anyone who has run a multi-site network knows the drill. A dashboard per vendor. A different idea of what a device is in each one. And no honest answer to the only question that matters: is this estate built to our standard?

Not “is it up.” Built to standard. Right SSIDs, no legacy protocols where they are banned, firmware that is not on a known-exploited list, hardware that is not quietly aging out.

I wanted one normalized view of the fleet across every vendor, scored against standards the tenant defines, with remediation behind approval gates. The vendor layer had to be a plugin bridge, because the one thing I know about network estates is that the next site brings a vendor you did not plan for. A new vendor should be an integration, not a project.

That became Synapse.

The Endpoints Kept Going Too

The endpoint platform, the one this whole company started from, grew as well. Twenty years of my career happened in warehouses and factories, and the devices that actually run those places are not servers. They are ruggedized scanners on the floor, and the tooling that manages them is some of the most stagnant in the industry.

One endpoint model, from the datacenter to the warehouse floor, in one console. That product is called Relay, and the ruggedized side is being built on the same model the servers already use: capture state, act, compare, roll back on drift.

Suite or Sprawl?

So the count is six. Relay for endpoints. Beacon for the service desk. Synapse for the network. Portal for identity. Meridian for compliance. Keystone running the commercial side.

At some point you have to ask the question I would ask any vendor who told me that: is this a suite, or is it sprawl?

I started Cadres because of sprawl. Six agents on a server. Four tools that did not talk. The snowball post was about exactly this. It would be a strange outcome to spend two years building my way back to the disease.

Here is the rule that keeps it honest: every product stands alone.

Each one ships with its own vendor integrations and does its whole job without the others. Beacon runs against Intune and Jamf whether or not Relay exists. Synapse scores a Meraki estate whether or not anyone files tickets. Meridian collects evidence from connectors, not from a hard dependency on the rest of the stack. The connections between Cadres products are bridges: explicit, optional, and doing nothing until you turn them on. Identity is the one exception, because Portal ships included with everything, and nobody has ever complained that sign-on was too consistent.

That is the difference, and it is architectural, not marketing. A platform that needs all of itself to be useful is a lock-in strategy wearing an integration story. A set of products that work alone and get better together is just tooling that respects how people actually buy.

The Cost, Stated Plainly

Building six products instead of one has a cost and I am not going to pretend otherwise. It is the same trade I described in the last post, made larger. Everything is in beta or early access, and every page on the site says which, because the people these tools are for have been burned by vendor optimism before.

What I will say is that the six share one discipline, and it is the same one from the first post: automate the routine, verify the result, involve a human by exception. Patching compares state and rolls back. Journeys in Beacon are deterministic and traced. Device-writing actions in Synapse wait for approval. The close engine in Keystone refuses to freeze an unbalanced sheet. One idea, six instruments.

The snowball did not stop. I stopped fighting it and gave it rules instead.

If you are running a stack of tools that each needed the others to be useful, and you would rather have ones that do not, start a trial.