Custom Computer Aided Dispatch: What It Really Takes to Replace a Decade Old CAD in a 911 Center

The parallel notes on the second monitor

Walk a floor at 2am and look at what dispatchers actually use. The CAD is on the main screen. Next to it there is a text document, a whiteboard photo, or a shared spreadsheet with the things the CAD cannot hold: which medic is actually staffed tonight, that Engine 4 is out of service for a pump issue but still shows available because nobody wants to fight the status screen, the gate code for the industrial park, the mutual aid contact who answers after midnight. The recommendation the CAD makes is wrong often enough that dispatchers override it as a habit, and once overriding is a habit the recommendation stops being a safety net and becomes noise.

Then a call comes in that needs a unit from the neighbouring agency. That transaction is a phone call. The CAD records that a unit responded, eventually, if someone types it. Six weeks later the chief asks how many times the department relied on mutual aid last quarter, and the answer is assembled by hand.

Why the change order queue is the real complaint

Directors rarely call us because the CAD screen is ugly. They call because every connection to anything costs money and takes a year. Station alerting is a change order. A feed to the records system is a change order. Getting a live data stream out for the county dashboard is a change order plus a licensing conversation. The ePCR interface is a change order and it only carries half the fields. Each one is quoted, queued behind other customers, and delivered on a schedule the center does not control.

That is the economics of the market, and it is not irrational: CentralSquare, Tyler New World, Motorola PremierOne, Mark43 and Hexagon OnCall carry enormous certification, redundancy and support obligations, and interfaces are custom work for each site. But it means the center's ability to change how it operates is capped by a vendor's roadmap, and over a decade that cap compounds into parallel notes on a second monitor.

What CAD products actually fail at

• Deployment logic that matches your agency. Unit recommendation ships as closest unit by drive time or a station order list. Real deployment is messier: cross staffed apparatus where one crew can be an engine or a medic but not both, move up rules that reposition companies as the map empties, tiered EMS response with a first responder plus a transport unit that may come from a private provider, and a chief who wants a specific truck on a specific box regardless of proximity. Products bend toward this. They rarely land on it.
• Your data, in real time, on your terms. Most centers can get reports. Far fewer can get a live stream of incidents and unit status into their own database for dashboards, analytics or a public transparency feed without a paid interface and a licence discussion.
• Cross agency boundaries. A call at the edge of the jurisdiction that needs the closest engine regardless of which department owns it is an automatic aid problem, and automatic aid across separate CAD systems is where products are weakest.
• Speed at the keyboard. Experienced dispatchers work in muscle memory. A product that adds two clicks per transaction costs you seconds on every call, and seconds are the currency of the room.
• The interface set as a whole. Individually each interface exists. Collectively, keeping CAD, records, ePCR, station alerting, mapping, mobile and radio consistent through upgrades is the ongoing tax nobody quotes at purchase.

The build most centers should actually do

Here is our opinion, stated plainly, and it costs us revenue to say it. For the majority of centers, replacing the CAD core with a custom build is the wrong project. The core is not the interesting part. It is the part with the hardest non functional requirements: it runs continuously, a failure during a working incident is a headline, and it needs redundancy, failover, tested backups and a support model at 3am on a holiday. Building that is possible. Owning it for ten years with a public agency's staffing and budget cycle is a different question, and it is the one that sinks projects.

The build that pays reliably is the layer around it. Take a real time feed out of the CAD, into a database you own. From there, everything the vendor quotes as a change order becomes your project on your schedule: dashboards for the deputy chief, unit hour utilisation and response time analysis without waiting on a report writer, a station alerting integration, a records prefill so officers stop retyping, an automatic aid bridge that lets two centers see each other's unit status, a public incident feed with the addresses handled per your disclosure rules. In our delivery experience that layer runs $90,000 to $220,000 and ships in 3 to 6 months, and it removes most of the pain that made you consider a replacement.

If you are genuinely replacing the core, here is the scope

Some centers should. A large consolidated regional PSAP dispatching for many agencies with deployment logic no product models, or a center whose vendor is sunsetting a product and pricing the migration like a new purchase, are real cases. The scope is not negotiable in the way people hope.

The core is incident creation and lifecycle, unit status with a model you define, recommendation that runs against your run cards and move up rules, mapping with your own address points and boundaries rather than a commercial geocoder, and a dispatcher interface that is keyboard first. Around it sits mobile for units in the field with its own offline behaviour, station alerting, radio and telephony integration, records and ePCR feeds, and the NG911 side so a call arriving with location and text lands in the incident rather than in a separate window.

Then the requirements that decide whether it is a real CAD: redundancy across sites, an automatic failover you have actually tested with dispatchers on the floor, a documented degraded mode when the network is gone, criminal justice information security controls including proper authentication and full audit, and a support rotation with a human who answers at 3am. Every one of those is engineering cost, and centers that skip them do not have a CAD, they have an application.

What it costs and how long it takes

From our delivery experience: the surround layer at $90,000 to $220,000 in 3 to 6 months. A single agency dispatch core with your recommendation logic, mapping and a mobile client at $180,000 to $400,000 over 6 to 10 months. A multi agency CAD with the full interface set, station alerting, redundancy and tested failover at $500,000 to $1.2M over 12 to 24 months, plus an ongoing engineering commitment that does not end at go live.

Cost drivers: the number of agencies and whether their status models and run cards differ, which they always do. The interface list, since each one is a separate negotiation with a separate vendor. Your GIS data quality, because address points, road centerlines and response boundaries have to be authoritative and most jurisdictions discover theirs are not. Redundancy architecture, because a second site is not a line item, it is a design constraint from day one. And cutover, which for a CAD means running parallel and training every dispatcher on every shift, measured in months not weeks.

When buying is the right call

Buy if you are a single agency center under roughly 50,000 calls for service a year. The economics are not close, and your energy is better spent on the interfaces and the data feed.

Buy if your state or region operates a shared CAD you can join, since interoperability with neighbours is usually worth more than a perfect fit.

Buy if you cannot commit to permanent technical staff. A CAD you own but cannot maintain is worse than a product you complain about, because the complaint at least has a phone number attached.

Build the core when you are a large consolidated or regional center, your deployment model has defeated two procurement attempts, you have or can hire real engineering capacity, and you can fund a decade rather than a project. Build the surround layer in almost every other case, immediately, because it is cheap relative to the pain and it makes the eventual procurement decision an informed one.

How to choose a developer

Ask them what happens when the network between the dispatch floor and the server room drops mid incident. A developer who has done public safety talks about degraded mode, local caching, reconciliation and the written procedure the dispatcher follows. A developer who talks about uptime percentages has built business software.

Ask them to model unit status for cross staffed apparatus. If they cannot represent one crew that can be an engine or a medic but never both simultaneously, they have not looked at how fire and EMS actually deploy.

Ask what they have integrated by name. Station alerting hardware, a specific records system, a specific ePCR, a logging recorder. Public safety interfaces are not generic APIs and the difference between a vendor with a documented interface and one with a database you can read is months.

Ask how they handle criminal justice information security requirements, including authentication, audit logging and personnel screening for anyone who touches the environment. If this is news to them, stop.

Ask who owns the code, the infrastructure accounts and the data, in writing before kickoff. At Digital Heroes it is yours from the first commit. Then make your first move the cheap one: get a real time copy of your own CAD data into a database you control, and see how many of your complaints survive having your own data.