Fireside with the maker of Deadlinewatch

I write here about deadlines and the work of carrying them. This one is more personal. It’s the tool I built, the reasons under it, what I drew on, and what it cost to make. The fireside version, so I’ll just talk.

Why I built it

I spent twenty years carrying other people’s deadlines for a living. Not a few. Many, at once, all the time, the kind of load where the dates live in your head and follow you home. And for twenty years I never found a way to hold them that I trusted. I tried the calendars, the planners, the task apps, the notebooks. Each one helped a little and missed the thing that actually weighed on me.

I knew there had to be a better way, because the problem felt solvable. That’s the instinct of anyone who solves hard problems for a living. You see a thing that doesn’t work, and you don’t accept that it can’t. So I treated this the way I’d treat any hard problem. I started from a hypothesis about what was really going wrong, and I worked backward to the tool that would prove it.

The hypothesis was simple, once I had it. The trouble was never the number of deadlines. It was that every tool drew them as a flat list, while my mind held them as something with weight and shape. Close that gap, I thought, and the load eases. The rest of the build was reverse-engineering from there.

There’s a softer reason underneath the engineering one, and I’ll say it plainly. I wanted to take what twenty years taught me and hand it to someone else carrying the same weight. A lot of that struggle isn’t necessary. It comes from the tools, not the work. If I could lift even part of it off another person’s shoulders, that felt worth two years of my life.

What I drew on

I didn’t invent the ideas under Deadlinewatch. I borrowed them, mostly from people who studied how the mind actually works, decades before there was an app to put them in. The inspiration was research, and I want to give it its due.

The starting point is old. George Miller fixed the capacity of working memory at about seven items, plus or minus two, back in 1956, and the number has held up better than almost anything in the field. Past that handful, the mind stops holding a clean list and starts straining. That’s the threshold where a deadline tool either earns its place or gets in the way.

The shape idea has a name too, and it isn’t English. The early Gestalt psychologists, Wertheimer chief among them, described how we take in a whole at once rather than building it up from parts. A week of deadlines is exactly that kind of whole. You don’t read it item by item. You read its shape. I built the tool to render that shape instead of flattening it.

Then there’s the part that explains the low hum you carry on a heavy week. Bluma Zeigarnik showed, back in 1927, that unfinished tasks sit in the mind more insistently than finished ones. An open deadline is an open loop, and open loops pull at your attention until they close or you put them somewhere you trust. Half the value of the tool is just being that trustworthy place to set them down.

Two more shaped the harder calls. Kahneman and Tversky’s work on the planning fallacy explains why we chronically underestimate how long things will take, which is why an outside view of your own week is worth having. Buehler, Griffin and Ross put numbers on it in 1994. And the same pair’s work on how we weigh losses against gains settled a real argument in the build. A missed deadline is a loss, and a loss weighs more than the equivalent gain, so a tool whose whole job is memory cannot default to staying quiet.

Cal Newport’s Deep Work named the cost I felt every Wednesday afternoon, the tax attention pays each time it switches context. And when I had to decide how often the tool should speak, a field experiment by Fitz, Kushlev and colleagues pointed the way. People whose notifications were batched and predictable did better than those getting a constant stream, and better than those getting none at all. Quiet, but present. That became the rule for the reminders.

None of this is decoration. Each idea changed a decision in the build, and the tool is the sum of them.

How it was shaped

A hypothesis is just a guess until something tries to break it. So I put the tool through more rounds of testing and feedback than I’d care to count, and I leaned on a few different kinds.

One was AI-assisted battery testing. I built independent evaluators, each given a specific working life, and told them to use the real product and report honestly where it would fail them. It turned out to be very good at finding the falsifiable problem, the bug or the bad default that hides from the person too close to the work. It caught things I would have shipped.

But software isn’t only logic, so I didn’t stop there. My partner and my friends used it and told me where it felt wrong, which is a different and harder kind of feedback to hear. And I used it myself, for months, in every form it took, the way you can only test a thing by living in it. The dashboard at six in the morning. The reminder landing while I was away from the screen. The week that suddenly went heavy. You learn things from daily use that no report surfaces.

The feedback didn’t always agree with me, and that was the point. The tool you’re looking at is the one that survived all three.

The hardest part

People assume the hardest part of building something is the building. It wasn’t, for me. The hardest part was rebuilding.

Every real pivot came from the same place. A piece of feedback, or a round of testing, showed me that something I’d made and was proud of was wrong. And then I had to go back and tear it out, or rebuild it, after I’d already convinced myself it was good. That takes a kind of inner strength I didn’t know the work would ask for. Adding feels like progress. Looking at something you built well and admitting it has to change, or go, does not.

Cutting features is the worst of it, because it runs against every instinct you have as a maker. The instinct says more. The evidence kept saying less. I learned to trust the evidence over the instinct, and almost every time I did, the tool got better. It never once felt good in the moment. It felt like loss, right up until the tool was quieter and faster and I remembered why I’d done it.

So that’s the real story of how Deadlinewatch got made. Not a straight line from idea to product, but a long argument with myself, settled by evidence, again and again, until what was left was only the part that earned its place. If the tool feels calm and sure now, it’s because the making was anything but.