How to Buy Public Safety Software: A Practical Guide

Public safety software evaluations often begin with a spreadsheet full of features. Vendors receive the list, check boxes and demonstrate as many capabilities as they can. The product with the most boxes checked can still be the wrong choice.

Departments do not wake up needing features. They need to reduce missed certifications, improve staffing, follow up with applicants, communicate critical information or eliminate hours of duplicate reporting. And when they buy software, they are choosing more than a product. They are choosing the people, processes and business that will stand behind it when it is needed.

This guide walks through the buying process step by step, from defining the problem to signing a contract you can live with, and ends with a checklist your evaluation team can copy.

1Step 1: Define the Problem Before the Product

"We need a scheduling system" is not yet a problem statement. The real issue may be that officers spend hours filling vacancies, unqualified members claim positions or nobody knows coverage until the shift begins. Those details determine what the software must accomplish.

Document:

• The current workflow and the people who perform it
• The information and systems involved
• Delays, errors, duplicate entry and workarounds
• Operational or compliance consequences
• The result leadership expects to improve, and how you will measure it

Talk with the people doing the work and follow a task from beginning to end. Leadership may believe a process takes three steps while the administrator performing it knows it takes twelve, two spreadsheets and a text message to someone who remembers the missing information. If the process itself is inconsistent, fix that first; software will only speed it up. (More on that in Standardize Before You Digitize.)

Then separate four levels of need:

1. Mandatory: the solution cannot meet the agency's need without it.
2. Highly desirable: creates meaningful value but may have an acceptable alternative.
3. Optional: worth considering if it does not undermine priorities.
4. Future: not required now, but relevant to roadmap and scalability.

Requirements should protect the outcome without prescribing every design decision. You may require proof that members acknowledged a policy without dictating where the acknowledgment button sits. Use "must" only when you are prepared to reject a solution that cannot meet it; too many mandatory items eliminate useful competition.

2Step 2: Build the Team and Plan for How Agencies Actually Buy

Agency purchases do not move in a straight line. By the time anyone talks to a vendor, the internal conversation has usually been going on for months, and the decision involves several people who move at different speeds and need different proof:

• The chief or director cares about outcomes and exposure.
• End users care whether it works at 2 a.m. and whether it adds friction.
• IT and records staff care about integration, security and support.
• Finance cares about total cost and the budget cycle.
• A council, board or oversight committee may need to approve the spending, often knowing the least about the operational problem.

Create a small core team that represents these views, including ordinary users and administrators, not only leadership. Assign one project owner to coordinate decisions, schedules, questions and vendor communication. Decide up front who approves requirements, who scores proposals, who attends demonstrations and who makes the final recommendation. Require evaluators to disclose conflicts.

Plan for the places purchases commonly stall: budget timing, a champion who has to explain the purchase to people who never saw the demo, security and procurement review, competing priorities after a bad incident or leadership change, and consensus fatigue, where doing nothing becomes the easiest outcome. None of these are surprises. Build them into the timeline.

3Step 3: Choose the Procurement Path and Structure Your Requirements

Confirm with procurement and legal staff whether an RFP is required. A request for information, cooperative contract, competitive quotation or pilot may fit the scope and local rules better. Either way, research the market first: talk with peer agencies, associations and IT leaders, and consider a non-binding RFI to learn terminology, integration approaches, typical pricing and realistic timelines. Do not copy one vendor's product page or another agency's RFP without confirming it matches your workflow.

Give vendors enough context to propose accurately: agency type and structure, number of members and administrators, stations, permission groups, current software and contract dates, required integrations, devices, identity and accessibility requirements, retention and security policies, and your target launch date.

Write requirements around workflows, not screens. Instead of "the system must include a dashboard," explain what the user must see, which decisions it supports, how often it updates and who can see it. Useful scenarios include a member uploading a renewed certification that needs officer approval, a scheduler filling a position that requires a specific qualification, a supervisor sending a critical policy update and confirming acknowledgment, an integration that stops updating over a weekend, and a request for a complete export before renewal.

Ask vendors to classify each capability as standard, configurable, custom development, partner-provided, planned for a future release or not available, and to explain any partial answer. A simple yes or no can hide important limitations.

4Step 4: Run the Demo on Your Terms

A demo is a performance. It is rehearsed, it follows a script and it is built around a path where everything works. That is the point of a demo, and there is nothing dishonest about it. But a polished walkthrough tells you almost nothing about what happens when certification data arrives incomplete, two people share a name or a member returns from a leave of absence. Polish tells you the company is good at selling. It does not tell you the system fits how your department works.

Before the demo, write down three or four real situations with some friction in them, and give every finalist the same scenarios, users, data conditions and time limits. A sample script:

1. Complete a routine user task from a phone.
2. Show an administrator configuring the workflow.
3. Demonstrate permissions for two different roles.
4. Handle missing or incorrect information.
5. Show reporting and a full data export.
6. Demonstrate an integration and its error status.
7. Show the support path when something fails.

Ask what the demo is not showing you, including the administrative side your administrator will live in every day. A vendor who says "let me show you exactly how that works" has a real answer. A vendor who pivots back to an easier example did not have one. Have evaluators score individually before group discussion, and require current production functionality, with prototypes, partner products and roadmap items clearly labeled.

Where possible, run a real trial with your own data and the people who will use the system daily. A vendor-prepared sandbox hides the friction a trial reveals. If a vendor resists a meaningful trial, treat that as information. If the product leans on AI claims, make the vendor explain exactly what the feature does and what happens when it is wrong; see The AI Feature Is Not the Product.

5Step 5: Vet the Vendor Behind the Software

New tools have made it easier than ever to launch a polished public safety platform, sometimes run by one person. Many are built by firefighters, medics, officers and dispatchers who know the work, and some will be excellent. But building useful software and operating a dependable software company are not the same thing. Ask every vendor, large or small, the same six questions, and apply them to anything built internally too.

1. How is our information protected? Ask for written security policies, encryption in transit and at rest, multifactor authentication, who can access customer data, how vulnerabilities and patches are handled, and whether there is a searchable audit log of who changed what and when. Ask who investigates an incident and how quickly you will be notified. Can the vendor prove it?
2. What does support actually look like? Is this a full-time business or a side project? Is support one person's inbox or a ticketed system with documentation and escalation? Who monitors uptime, how is it measured and what is excluded? How are customers told about outages, and are backups tested?
3. What happens if a key person leaves or becomes unavailable? Ask who can access the source code, hosting, domains, customer records and backups if the owner or a critical employee is ill, retires, quits or is terminated. Critical resources should belong to the company, not an individual's personal account, and access should be role-based, logged and removable immediately.
4. Does the pricing support a sustainable business? Hosting, security, support, integrations and ongoing development all cost money. Low pricing is not automatically bad, and high pricing does not guarantee quality, but the vendor should be able to explain how its business model pays for the service it promises.
5. Would an internal build meet the same bar? A system built in-house may feel free, but staff time, infrastructure and long-term support still cost something. Ask the same questions about security, backups, documentation and portability, and make sure more than one person has access so the agency does not create a new single point of failure.
6. Does it meet our compliance requirements? Depending on the data, that may include PII, HIPAA, criminal justice information, public records, retention, audit logs, cyber insurance, vendor risk reviews or standards such as SOC 2. Ask about accessibility under the ADA and WCAG, and whether the product is truly usable on a phone.

6Step 6: Check Integrations, Not Claims

Do not accept "integrates with" as a complete answer. For each required connection, identify the source and destination, the data exchanged, the direction and update frequency, the method (official API, file exchange or something more fragile), authentication, costs, error monitoring and which party supports it when it breaks. Ask the vendor to demonstrate what works today. An integration that needs ongoing manual maintenance is a recurring cost with an automated appearance. For more on this, read Public Safety Doesn't Need More Disconnected Software. It Needs Platforms That Work Together.

7Step 7: Build the Total Cost of Ownership Yourself

A quote answers "what does the license cost." You need to know what the system costs to run for as long as you plan to use it, and almost nobody quotes that number. Ask for multi-year pricing with stated assumptions, and mark each charge as one-time, recurring, estimated or dependent on a third party. Never compare one vendor's base package with another vendor's complete implementation.

TCO worksheet: estimate each line for every finalist

• Subscription or license, including which modules are included and how price scales with members, admin seats, locations or storage
• Renewal terms, including any cap on annual increases
• Implementation and project management, plus your own staff hours
• Data migration, cleanup and validation, including historical records
• Configuration and any custom development
• Integrations: included versus custom-built and separately priced
• Initial and ongoing training for new officers and administrators
• Support tiers and premium support costs
• Hardware, devices and travel
• Ongoing administrator time per week, confirmed with current customers of similar size
• Exit costs: termination fees, auto-renewal terms, export fees and a second migration if you ever switch

8Step 8: Test the Exit Door Before You Sign

Nobody asks about leaving during the demo, but the exit question belongs in procurement. The department should own its data; the vendor owns the software. The real test is what the export function does, because ownership without a working export path is a promise, not a capability.

Ask for a sample export during the evaluation and have someone who understands the data open it. Does it include history or only current status? Does it keep relationships, like which certifications belong to which member? Are attachments included, or only filenames? Is it in open formats such as CSV, JSON and PDF, or a proprietary format only the vendor can read?

Then read the termination section as carefully as the pricing section. How long after termination can you export? Thirty days is common and often too short. What happens to the data afterward, and on what schedule? Is there an export fee? The department has the most leverage the day before it signs and almost none the day after it wants to leave.

9Step 9: Check References and Treat the Contract as an Operational Document

Talk with agencies of similar size, structure and integrations, ideally ones that have used the system for at least a year, without the vendor present. Ask what took longer than expected, what required more agency effort, which capabilities did not work as demonstrated, how support responds during serious problems, whether pricing stayed predictable and whether they would choose the vendor again.

The contract must match the winning proposal. Incorporate the proposal, security responses and clarifications by reference, and cover data ownership, export format, post-termination retention, security incidents, service levels, renewals, implementation acceptance and transition assistance. Operational leaders should read it alongside legal counsel; they are often best placed to spot a promise that does not match the real workflow. Define acceptance as more than go-live: completed migration, working integrations, documented training and resolved critical defects.

10Step 10: Score and Document the Decision

Build the scoring model before proposals arrive. A sample weighting:

• Operational and functional fit: 30%
• Security, privacy and continuity: 15%
• Demonstration and workflow validation: 15%
• Usability and accessibility: 10%
• Implementation and migration: 10%
• Support and vendor capability: 10%
• Total cost: 10%

Adjust the weights to the project, define what excellent, acceptable, weak and noncompliant look like, and keep mandatory pass-or-fail items separate from scored preferences. Price should matter, but the lowest initial price can lead to higher migration, support or long-term costs. Keep evaluation records according to procurement and public-records rules, and write a recommendation that explains why the selected solution best meets the agency's outcomes, not just its final score.

Public Safety Software Buying Checklist

Before making a final selection, confirm your team can answer yes to each item:

Features matter, but they are ingredients. The result that counts is whether the department operates more effectively, with a vendor it can trust long after the sale.