From firefighters, for firefighters

At our station, every incident begins with a sheet of paper.

The Einsatztagebuch — the operations logbook — sits in the command vehicle or the radio room, and somebody writes down every message: who called, who answered, what was said, and when. This is not paperwork for its own sake. It is a legally relevant record that may still have to answer questions months later. And it is produced with cold fingers, at night, while the next radio call is already coming in.

We stand in that radio room ourselves. That is exactly why we are building Einsatzlog.

We already tried this once

This is not the first attempt. Some time ago we experimented with a digital logbook already. It turned into a real, working prototype — one that ran on the desk, impressed a few people, and was never released.

That belongs at the start of this story, because it explains why we are doing it differently now. What went wrong back then was not the technology:

• We started with the data model instead of with the radio operator. The database was clean; the handling was not.
• There was no deadline. A project without a deadline is a project that never finishes — it just keeps getting nicer.
• Features kept arriving before the one feature that matters was solid: capturing a radio message fast.
• And we questioned a few dependencies too late. A PDF library that boxed us in on licensing only became a problem once two prototypes were already built on it.

None of this is dramatic. Taken together, though, it is the reason the app does not exist. We are saying it plainly, because a promise from someone who has already failed to deliver is only worth anything if they mention that part.

What is different this time

This time it gets the full effort, and this time the frame is set so that “done eventually” is not an option:

There is a hard, public deadline. Einsatzlog is being built for a developer challenge whose rules are uncomfortable: the app has to be genuinely released in the app stores inside a fixed window. No more eternal prototype.

Interaction first, code second. It did not start with class diagrams but with three sketches on squared paper — home screen, logbook, entry form. They are the origin of every screen, and they live in the repository.

Every feature starts as a written spec. Goal and acceptance criteria first, code afterwards. It sounds like bureaucracy; it is the reason nothing quietly gets out of hand this time — and it makes “is this feature actually done?” a checkable question.

Everything is public. Not just the source. The sketches, the specs, the schedule with its dates — and the mistakes. If you want to know whether a claim on this website is true, you can go and check:

👉 github.com/Einsatzlog-Team/etb

What we are not promising here

No feature list. No dates in a blog post that quietly disappear later — the dates are in the roadmap in the repository, where they can be held against reality. And we are not revolutionising anything. We are trying to do one single thing better than a ballpoint pen, and the pen is a tougher opponent than it looks.

Two things we will commit to now, because they are not features but a stance:

The app stays free. Fire departments have no app budget, and they should not need one.

Incident data stays on the device. No account, no server, no analysis. What happens in the radio room stays in the radio room.

Follow along

This blog documents every step: what got built, what worked, what did not, and what it cost us. The next post goes back to the three napkin sketches that started all of it.

If you are a radio operator yourself and want to tell us what is actually printed on your paper form — write to us. That is exactly what this is for.

#BuildInPublic