Why I Built BabbarOps

I'm a California patrol sergeant who got tired of watching critical information die between the people who needed it most. BabbarOps is what I built so that every role, from patrol to SWAT to investigations to command, sees the same live incident at the same time.

It always begins as something smaller than it becomes. An officer makes contact on a call that reads routine. Then a shot, a door, a barricade, and in one breath the whole net changes pitch.

The radio fills with echoes and half-words: units stacking on top of each other to say they're rolling, dispatch holding the line, phones lighting up between responders, between command, and up the chain to staff who heard something happened and want to know what. You can feel the anxiety in the air before anyone names it. A good incident commander is the person who walks into that and brings the calm: organization, focus, a mission everyone can hear.

I've been the one bringing that calm. I've also been every other seat: first on scene, the drone pilot overhead, the supervisor, the incident commander, and the viewer miles away trying to build a picture out of a voice. And from every one of those seats I kept hitting the same wall: the people making the decisions almost never had the same picture as the people standing in it.

Five seats, one problem

That gap looks different depending on where you're sitting, but it is always the same gap.

• As the drone pilot, I could see a suspect moving through a backyard the responding units couldn't, and the only way to move what I was seeing was to describe it over the radio, one sentence at a time.
• As the first officer on scene, I knew things in the first ninety seconds that the units rolling to me wouldn't hear until they arrived and asked.
• As the supervisor, I relayed the same details five times to five people who each called separately.
• As the incident commander, I ran operations off a whiteboard and a phone that would not stop buzzing, trying to hold a moving picture in my head while answering the same question on a loop.
• As the viewer (command staff, away from the scene), I waited on a description of something a camera was already watching.

Live video lived in one place. Assignments lived on a whiteboard. Intel was scattered across CAD, text messages, notebooks, and email. Everyone was working hard. Everyone was working from a different version of reality.

The first fix was getting video to command

I started with the piece that looked simplest: get the live feed reliably in front of the people making decisions. It turned out to be the part legacy hardware is worst at. To stream a drone feed to command the old way, you needed:

• The equipment: dedicated broadcast hardware, bought and maintained.
• Someone to set it up, and someone who actually knew how.
• Someone to build and share the stream links, every time, under pressure.
• Clean RF, which a chaotic scene almost never has.
• Cellular bandwidth: a hotspot fighting every other phone on scene.
• A server to host the stream, one more thing that can fail at the worst moment.

Stack six fragile dependencies and the whole chain stalls exactly when you need it most. I had watched capable people give up on the feed mid-incident and fall back to the radio, not because the drone wasn't useful, but because the plumbing between the drone and command had collapsed.

So the first thing my co-founder and I built was a version of Live Command that asked for one action from the field: the drone operator starts the stream from the same controller they are already holding. No extra box, no setup crew, no link-building. Viewers go to one place (the same portal, the same predictable URL for the agency) and watch. The reliability had to hold under stress, because that is the only condition that actually matters.

What I got wrong

The first version was rough, and the field told me so quickly. Live Command v1 stacked every feed vertically. To see the second camera you scrolled down. It was fine with one feed. The moment an operation had three or four, operators told me plainly what they actually needed: "I need to see them all at once, in a grid."

That feedback set the pattern for everything since. Layouts came next: small, medium, large, a full video wall, the ability to hide a feed or rearrange them on the fly. Then came the realization that the most available camera on any scene isn't a drone at all. It's the phone in a responder's or a witness's pocket. Send them a link, and their phone becomes a live feed on the same wall, with no app to install. I built what I assumed people needed. They told me what they actually needed. The product is what it is because I listened.

The video was never the real problem

Once the feed was reliable, I expected the chaos to settle. It didn't, not all the way. We had fixed the video and the operation could still come apart, because the video was only ever one input. The assignments were still on a whiteboard. The intel was still scattered. The incident commander still had a buzzing phone.

That was the turning point. The problem I had actually been living wasn't a video problem. It was a shared operational picture problem.

The first version of Incident Command was nothing more than a digital whiteboard: a shared place to put the things that used to live on a wall only the people in the room could see. It was simple, and it was the most important thing we had built, because for the first time the picture lived somewhere everyone could reach.

Build the incident once

From there the idea was straightforward: build the incident once, and let every role inherit it instead of starting over.

It starts with the incident commander, because they carry the chaos. Give the IC a place to organize (resources tracked, needs anticipated, units deployed deliberately) and the confidence to bring calm instead of managing a phone. Then give every responder that same live picture, so the IC isn't the human switchboard answering one question forever.

Then the supporting roles, each shaped by asking what would make that role's job easier:

• SWAT arrives into context instead of a cold briefing. The picture patrol already built is there waiting, so preplanning is faster and they deploy sooner.
• Investigations get the context they would otherwise reconstruct days later by calling around, and the tools to do the work the incident demands, like the warrants that come next.
• Command and leadership see the same incident as the people standing in it, in real time, without a phone call.

One live picture, from the first unit on scene to resolution, with the two platforms paired: Live Command for what the cameras see, Incident Command for everything else the operation needs to share.

The tools were never the problem. The gaps between them were.

Agencies are not short on tools. There is a system for video, a system for dispatch, a system for records, a radio, a whiteboard, a group text. Every one of them works. What fails is the space between them: the handoff, the relay, the re-brief, the phone call that has to happen because two systems don't talk to each other.

I built BabbarOps because I got tired of watching information die in those gaps, between the people who needed it most. Every delay was another radio transmission, another phone call, another briefing, another chance for the picture to drift apart. I wanted everyone, from the first officer to SWAT to the detective to the chief, to see the same incident at the same time.

Who built this

I'm a California patrol sergeant and former UAS team lead. I have worked critical incidents from most of the seats around them, and the product comes from those seats, not from a whiteboard in an office, but from the specific frustrations of doing the job.

My co-founder and I met at university years ago and have been friends since: I was finishing an unrelated bachelor's degree while he earned a master's in software engineering. I had the vision; he had the ability to make it real, and the discipline to build it to production standards. BabbarOps was built in the margins of a full-time policing career, which is exactly why it is shaped around how the work actually happens rather than how software companies imagine it does.

Where it stands

Live Command has been proven under real operational stress, the conditions it was designed for, not a demo. It is live-only by design: video is shown live and never stored by the platform, so each agency's existing evidence system stays the system of record. Incident Command came afterward, built to close another gap I had lived: the shared operational picture that no single system held. It is the newer of the two and has not been through the same operational proving; it runs today in pilot with select agencies, on infrastructure built for government workloads.

The mission hasn't changed since the first stacked-feed prototype: one live picture, shared by every role, from the first call to the last unit clearing. The tools were never the problem. We built BabbarOps to close the gaps between them.

BabbarOps is an independent commercial product and is not affiliated with, endorsed by, or operated on behalf of any law enforcement agency. The founder's professional role does not represent the views or endorsement of any employing agency. This account reflects personal experience and general operational conditions; it does not describe any specific incident, operation, or agency.