AI Is Creating a New Generation of Public Safety Entrepreneurs. Ask the Hard Questions.

I have told my team that our new competitors are not just the traditional companies we have watched for years. Our competitors are now everyone. That includes new entrepreneurs, our existing partners and, yes, even our own clients.

AI has made it exceptionally easy for someone with a strong idea and enough determination to create a sophisticated platform, connect it to third-party applications through APIs, launch a polished website and produce marketing material that looks like it came from a Fortune 500 marketing department.

Honestly, I wish I had these tools when I created Firehouse.com. I spent a lot of nights sitting on my couch with a laptop, hand-writing HTML. I am not even sure CSS was really a thing yet, at least not in my world.

I use AI constantly across my own businesses now, and sometimes my brain is practically drowning in ideas because of everything that suddenly seems possible. Some nights I have two dozen AI agents working across numerous projects at the same time. I am sure that drives my team at least a little insane too. Every new capability leads to five more ideas, three more potential products and another list of things I want us to improve. It is amazing and overwhelming all at once.

So I applaud what is happening now. I really do.

It also motivates me. It pushes me to think more creatively and move more aggressively. It challenges my team and me to look at how quickly we can enhance the many products and services we already offer. Small, focused competitors can absolutely outflank larger companies. They are often more nimble, they can make decisions quickly and they do not have layers of process standing between an idea and a release.

All of this makes me excited, competitive, jealous and more innovative at the same time.

But there is another side to this conversation.

When a fire department, EMS agency, law enforcement agency or local government considers moving mission-critical operations, personnel information or other important data to any new platform, there are questions it needs to ask. Those questions matter with every vendor, whether it is a one-person startup, an established company or something built internally.

Many of the people creating these new platforms are firefighters, EMTs, chiefs, police officers, dispatchers and other public safety professionals. They know what departments need because they live it. They see the gaps, frustrations and complications in the software their agencies use every day. They also know which platforms their departments avoid because they are too complicated, convoluted, unfriendly or, in some cases, just archaic.

I completely understand why they decide they can build something better. Often, they may be right.

And do not get me wrong. I have absolutely launched platforms and businesses with just me, or with one or two other people. I have lived this. I have also learned the many lessons that come with growing from a few early customers who heard, “Hey, I’ll give this to you for free if you use it and give me feedback,” to being involved in businesses that now support more than 2,000 public-safety customers. Those customers range from small volunteer fire departments with 20 members to some of the largest departments in the country.

I know what it is like to start small, do nearly everything yourself and figure things out as you go. I also know how different the responsibilities become when agencies begin depending on what you built. The product may have started as an idea on your laptop, but once customers trust it with their operations and information, it has to become much more than that.

I also come to this with nearly 40 years of experience leading or supporting my own fire department. Many of my earliest business ideas grew directly from things I knew my department needed. We needed a better website. We needed better recruitment marketing and a better way to track prospective members. We needed better tools to manage the department and its reporting. At one point, I simply wanted to replace the Polaroid photos we taped to a wall to welcome new members. Three months later, I owned a digital-signage business designed to do that and a whole lot more.

That is how many public-safety businesses begin. Someone inside a department sees a real problem and thinks, “There has to be a better way to do this.” I have lived that process repeatedly, which is exactly why I respect the firefighters, EMTs, chiefs, officers and others doing the same thing today.

Building useful software and operating a dependable software company are not the same thing.

Here are the questions I believe every agency should ask.

Questions Every Public Safety Agency Should Ask Before Choosing Software

1How is our information protected?

Start with security.

For me, AI makes it possible to develop ideas, concepts and working prototypes incredibly fast. But a fast prototype is not automatically a secure, production-ready product. I make sure the code, architecture and security are reviewed using best-in-class tools and by people who know what they are looking for. When something moves from an idea or prototype into production, real development standards and security practices have to move with it. There must be an ongoing structure to support testing, monitoring, maintenance and future innovation. It cannot simply be me running everything by myself and hoping nothing goes wrong.

It makes a real difference when you have experienced engineers, CTO-level resources and access to the funding required to do all of that properly. That is not a brag. It is a serious factor agencies need to consider when evaluating platforms that provide significant value but also have meaningful access to their data and information. A great idea and an impressive prototype matter, but so do the people, expertise and financial resources standing behind them once the platform becomes part of an agency's daily operations.

What is the vendor's security plan? How is critical agency data protected? How is personal information about personnel, members, employees or patients handled? What technical and administrative safeguards are in place?

Does the company have written security policies? How often are those policies reviewed? Who can access customer data? How are accounts and permissions managed? Are vulnerabilities monitored and addressed? Is data encrypted when stored and transmitted? Is there a robust, searchable audit log showing who accessed or changed something, exactly what they did, when they did it and, where appropriate, how the action was performed?

If there is a security incident, what happens next? Who investigates it, who communicates with customers and how quickly will your agency be notified?

The bottom line is simple: How secure is your data, and can the vendor prove it?

2What does support actually look like?

How quickly will the vendor respond when something breaks?

Is this the owner's full-time business, or is it currently a side project? There is nothing inherently wrong with starting something on the side. Plenty of great companies began that way. But an agency needs to understand what that means when it needs help at 2 a.m., during a major incident or at the beginning of payroll processing.

Is support handled entirely through one person's email inbox? Or is there a real support system with documentation, ticket tracking, escalation procedures and a record of prior issues?

Who monitors uptime? Who receives alerts when a service goes down? How are customers kept informed during an outage? How often is data backed up, and are those backups actually tested?

Most importantly, if you decide to leave, can you export all of your information in a usable format? Your agency's data should never be held hostage by a product or vendor.

3What happens if the owner dies, becomes ill or simply walks away?

This is uncomfortable to discuss, but it is not hypothetical.

Two years ago, the owner of a company that competed with our website business died unexpectedly. He was young, and it was tragic. His company served many customers across the country.

Within a month or two, almost all of those websites died with him.

Hosting bills and domain renewals stopped being paid. Sites went offline. In many cases, there were no accessible backups and no practical way for customers to recover their content. Unless a site happened to be captured by Archive.org, departments were forced to start over.

Even worse, some departments did not control their own domain names. When the company disappeared, part of the department's online identity disappeared with it.

The owner may have had some help. I do not know. But in a very small company, even one with an employee or two, the business may still depend entirely on one person.

Death is the most extreme scenario. What if the owner is hospitalized or incapacitated? What if they burn out? What if they retire, take another job or decide the business is no longer worth operating? What if they provide only a few months, or a few weeks, of notice?

Ask whether there is a documented continuity plan. Who can access the systems, source code, customer records, hosting accounts, domains and backups if the owner cannot? Is there someone who can truly step in, or does the entire operation stop with one individual?

4Does the pricing support a sustainable business?

If a platform is built internally, it may feel free. It may even save the agency a significant amount of money. Of course, the staff time, infrastructure, maintenance and long-term support still have a cost, even if they do not appear as a separate software bill.

Many of the new commercial platforms entering the market are also inexpensive. Sometimes, perhaps, they are too inexpensive.

I have seen several companies offer “lifetime subscriptions” to all customers or to their first group of adopters. It sounds like a fantastic deal. But what happens if the company stops attracting new customers? What if it does not grow fast enough to pay for customer support, hosting, security, maintenance, ongoing enhancements and all of the ordinary work required to run a business?

If customers are not paying monthly or annually, what powers the platform and pays its bills three, five or ten years from now?

Operating a dependable software platform requires real resources, regardless of whether the company is large or small. Hosting costs money. Security costs money. Support costs money. Maintaining third-party integrations costs money. Improving the product and keeping up with changing technology, regulations and customer expectations all cost money.

Someone charging $199 a year for an “all-in-one solution” may face very real challenges if the company attracts only a few dozen, or even a few hundred, customers. That math can be difficult even if the business is a side gig and the owner does not initially take a salary.

Low pricing does not automatically mean a platform is bad, and higher pricing certainly does not guarantee that it is good. But the vendor should be able to explain how its business model supports the service it is promising.

If the price seems too good to be true, ask even more questions.

5What about something built internally?

Maybe a firefighter, chief, IT employee or other staff member says they can replace a platform your agency currently uses with something built in-house and tailored to your exact needs.

Guess what? They may be right.

I am doing some of that within my own company now. We are bringing certain functions in-house that previously relied on third-party products. The difference is that these newly created internal systems are backed by developers, engineers, support staff, documented processes and a company structure that does not depend entirely on me.

If I get hit by a bus, the company and its systems will carry on. I will probably be the one most inconvenienced by that particular scenario.

An internal build should face the same scrutiny as an outside vendor. How are security, backups, monitoring and support handled? Is the data portable? Does the system meet the agency's or jurisdiction's IT security requirements?

What happens when the person who built it retires, transfers, gets promoted or leaves the department? Worse, what if they get fired, they are not happy about it, and they nuke what they built? Is the system documented well enough for someone else to maintain it? Does more than one person have access to the hosting, database and related security, monitoring and analytics tools, so the system is not locked to one person's login? Is there another person who can fully step in, or is the agency quietly creating a new single point of failure?

6Does it meet the compliance requirements your agency faces?

Public safety technology can involve sensitive information and a complicated set of responsibilities.

How does the platform handle personally identifiable information, or PII? If protected health information is involved, how does the vendor address HIPAA and related privacy requirements? Are appropriate agreements, controls and procedures in place?

What about accessibility? Has the vendor considered the Americans with Disabilities Act and the Web Content Accessibility Guidelines? Is the platform working toward meeting or exceeding applicable accessibility standards? Is it truly usable on mobile devices, not merely squeezed onto a smaller screen?

Depending on the agency and the type of data involved, there may be additional requirements around data retention, public records, audit logs, incident response, cyber insurance, vendor risk reviews or independent security standards such as SOC 2.

The bottom line is that it is a lot. A great feature list does not answer these questions.

Balancing Innovation with Due Diligence

I recognize that this post is self-serving. I create and sell platforms and services to public safety agencies. I am talking, at least in part, about competitors. That includes new single-person companies, internally built systems, other products entering the market because AI has dramatically lowered the barrier to building software, and current competitors that can now expand their offerings much more rapidly.

AI makes things possible today that would have required an entire development and marketing team just a few years ago. It is amazing.

I love innovators. I hate competitors. But I love what competition does to me.

It forces me to think harder, move faster and build better.

My message is not that departments should avoid startups, small companies or internal projects. Some of the best ideas in public safety will come from exactly those places, my own new projects included.

I am certainly glad no one looked at some of the things I built early on and said, “Wait, you’re just one dude.” Those first customers trusted me based on my background and experience, or perhaps they simply took it on faith. In reality, they probably did not know to ask many of the questions I am suggesting here. And, if I am being completely honest, I am glad they did not. I might still be sitting on my couch trying to land customer number one.

But those experiences are also why I understand both sides of this. Someone has to take a chance on a new idea and a new entrepreneur. That trust creates an obligation for the person building the product to grow the support, security, infrastructure and business behind it as customers begin depending on it.

The Bottom Line for Public Safety Agencies

My message is to ask a lot of questions before trusting any company or individual with your operations, your information and your people.

Ask what happens when things go wrong. Ask who is accountable. Ask whether your data is protected, backed up and portable. Ask who takes over if the person behind the product is suddenly unavailable. Ask whether the vendor has built a sustainable service, not just an impressive application.

And to the entrepreneurs, firefighters, EMTs, chiefs, officers and innovators creating these tools: Keep building. Keep finding gaps. Keep coming up with better ideas.

The fire service, especially, has traditionally been years behind the curve in many areas of technology. That is changing rapidly, and I am excited to be part of it.

Just make smart, informed decisions for your agency and your personnel. Innovation matters. So do security, continuity, support, accessibility and trust.

The best public safety technology needs both.

And yes, before anyone points out the irony, I used AI to help clean up and edit this post. Of course I did. I love AI. I just spent an entire article explaining why.

For a structured agency evaluation checklist, continue with the Guide to Selecting a Public Safety SaaS Vendor.