Case Study 06. 911Buddy, Nationwide Emergency Connectivity Platform
Industry: Public Safety and Mobile Technology. Timeline: 2014 to 2016.
The Problem.
In 2014, the 911 system did exactly what it was designed to do, and that was the problem. When you call 911, the system connects you to your local Public Safety Answering Point (PSAP), the 911 dispatch center for the area you are calling from. That is exactly right when the emergency is where you are standing.
But it left no path for the situation people only discovered in the moment they were in it, when the person who needed help was somewhere else. If you were in one city and needed to send help to an address in another, there was no way to reach that location’s 911 dispatch center. The system, working exactly as intended, kept you connected locally. A dispatcher in an isolated, high-tourist jurisdiction saw this gap constantly, because visitors in a crisis so often needed to reach somewhere other than where they were. The system was not broken. It simply had no answer for a real emergency it was never built to handle. That is where Kinetic Thoughts came in.
The Solution.
I co-founded 911Buddy and served as its CTO. I designed the full system architecture, directed the workflow and the UI/UX, and built the entire server-side backend myself.
The app gave a person three ways to reach the right 911 dispatch center for a location other than their own. You could type in an address, drop a pin on a map, or save the addresses of the people you might one day need to send help to. Whichever method you used, the app converted that location into geographic coordinates, sent those to a geolocation data service, received back the correct 10-digit direct number for that location’s 911 dispatch center, and placed the call.
Getting the call itself to work took some engineering. Dialing 911 directly from inside an app runs into an iOS safety feature that closes the app, so I built the system around direct 10-digit dispatch numbers and a telephony layer instead, which sidestepped the limitation and connected the caller to the correct center.
I also made the platform and vendor calls a CTO has to make. We built for iOS first as a deliberate economic decision. At that time, iPhone users were accustomed to paying for apps, while the Android market expected them to be free, so iOS was where a subscription product could actually earn its keep. I managed the outside development work as well. When the first firm did not work out, I sourced and directed a second one to build the mobile front end under an architecture I had already defined. And I negotiated the platform’s core data cost down by 75 percent, from $2,000 a month to $500, by getting the geolocation vendor to create a new lower-usage pricing tier that had not existed before.
There was a business to build too, not just the technology. I designed a dual subscription model that worked both inside and outside Apple’s payment system, and I built an affiliate program on top of it. Third-party sites could distribute the app using generated tracking codes and earn a share of the subscriptions they brought in.
The Outcome.
We built and operated a functioning nationwide emergency connectivity platform. It was not a prototype or a proof of concept. It was a working system that solved a genuine life-safety problem most people did not know existed, spotted from inside the 911 center by the person living it and made real by the technology we built around it.
We wound the platform down in 2016 as a business decision rather than a technical one. The engineering worked, but the unit economics did not close. Even after I cut the core data cost by 75 percent, the recurring data spend still outpaced our early subscription revenue, and there was nothing left over to fund the marketing that real scale would have required. We chose to stop rather than keep pouring money into a model that could not reach viability.
Looking back, it was an early, full-stack CTO engagement in everything but the title. I owned the architecture, built the backend, negotiated with vendors, managed an outside team, and designed the business model itself, years before “fractional CTO” became a common way to describe this exact kind of work.