Depth over breadth

The problem

Public safety software has a feature problem in reverse. Departments were not short on capability. A mid-sized agency might run a computer-aided dispatch system, a separate records management system, a messaging tool, and a mapping layer, each bought at a different time from a different vendor. The capability existed. It was spread across four systems that did not talk to each other.

That fragmentation surfaces at the worst possible moment. During an active incident, a dispatcher is switching between windows to pull an address history, log a unit, and reach an officer, while the call is still open. Every switch is a place to lose the thread.

The interfaces made it worse. Dispatch tools in particular were about a decade behind the software these same people used everywhere else in their lives, which pushed the burden onto training. Departments were spending weeks onboarding staff onto systems that should have been learnable in hours, and under pressure, officers could not reliably use the tools they already had.

What we found

We did more than fifty ride-alongs with police dispatchers, officers, and campus security directors before writing a line of code.

The finding that reshaped everything: departments were not failing because of missing features. They were failing because officers could not use what they already had when it mattered. Training time and onboarding complexity were the real barriers.

The second finding followed from the first. Fragmentation between dispatch, records, messaging, and maps was forcing constant context-switching during live incidents. Connecting those systems was not a nice-to-have. It was the product.

Constraints

Note pending.

Three bets

Three decisions defined what we built.

Dispatch before records. Existing CAD tools were a decade behind on usability, which made dispatch our clearest wedge. Records was the larger market but the weaker opening.

Owning messaging natively. We built phone and SMS ourselves rather than integrating a provider. Unified communications was core to the value proposition and we did not think we could outsource the part the product was actually about, even though building it raised our technical risk.

Building records management from scratch. We wrote a modern API-first RMS rather than integrating with legacy systems. That bought us speed and flexibility, and it cost us: we had to ask customers to migrate, which is a heavy lift to request from an agency with years of records in an old system.

What we cut

We scoped dynamic indoor mapping and agentic integrations, and cut both.

The agents decision was not about technology. The people those agents would have replaced, dispatchers, records clerks, community liaisons, were trusted figures inside their departments and their communities, not just job functions. Our customers did not want them automated away.

It was not our call to make.

The tradeoff

Depth over breadth, consistently.

A dispatcher during an active incident has zero tolerance for confusion. Every time we weighed adding capability against reducing cognitive load, we chose load. In practice that meant cutting features we had already scoped, simplifying flows we had already designed, and sometimes disappointing customers who asked for things we believed would damage the core experience.

Where it landed

One year from start. Three active department customers, plus Texas Christian University as our first enterprise account.