Should You Build It Yourself?
An honest decision framework. The maintenance burden, the bus factor, and the questions to answer before you write anything.

Build · Automate · Connect
AI-assisted development and low-code tools have changed what a technically curious fire or EMS professional can build without a traditional software team. That creates real opportunity for administrative tools, dashboards, prototypes and automation. It also creates risk when internally developed software begins touching sensitive data, operational decisions or mission-critical systems. The question this track keeps returning to is not just whether you can build it. It is whether you should build it, who will maintain it, and what happens when the person who built it leaves.
An honest decision framework. The maintenance burden, the bus factor, and the questions to answer before you write anything.
Some problems carry too much operational, clinical, personnel, records, cybersecurity or lifecycle risk to treat as an internal coding experiment.
What tools like Claude Code and Lovable make possible for someone who is not a developer, using a real example.
Pulling data out of CAD and RMS through their APIs, and automating the reporting nobody wants to do by hand.
The questions to answer before the first line of code: what data the tool touches, who can reach it, where it lives, and what happens if it is compromised.
Documentation, ownership, authentication, backups, dependencies, source control, and the handoff plan every internally developed tool needs.
A hands-on session taking a group from incident export to a working dashboard their department can use.
Pieces with a reading list point at the clearest outside treatment of the subject we could find and verify. If something here is wrong, missing, or in the wrong order for how a department actually works, that is worth knowing now.
Send a note