A conversation with the maker

# A conversation with the maker

I write about deadlines and how the work of carrying them actually gets done. The maker of Deadlinewatch reads what I write, so when I asked to interview them about how the tool was built and what it refuses to be, they agreed on one condition. No softballs. What follows is most of that conversation, edited only for length. The questions are the ones a careful skeptic would ask. The answers are worth reading because of where they stop being tidy.

You tested the product on users who don’t exist. Why would anyone trust that?

Because the alternative was testing it on no one. I built the thing alone, with no customers yet, and I had the oldest pre-launch problem there is. I was too close to my own work to see where it broke. So I made independent evaluators, each given a specific working life and a specific way of using the tool, and I told them to read the real product. Not the marketing. The actual built thing. Then report, honestly, where it would fail them.

The trust question is fair, so here is the honest version. A simulated user can’t tell you whether real people will pay. It can’t feel the thing. But it turns out to be very good at one job, which is finding the falsifiable problem. Give it the real artifact and an honest brief and it doesn’t invent hypothetical complaints. It traces actual ones. The proof isn’t that the method sounds clever. The proof is what it caught.

What did it catch that you’d have missed?

The one that still bothers me was the timezone. The product stored everyone’s timezone as a default, and no path through sign-in ever wrote the real one. For anyone not on that default, every word the tool says about time would have been computed against the wrong day boundary. Today, due today, overdue, the send time of a reminder. A deadline due today could read as overdue a day early.

Sit with that for a second. The entire promise of the tool is trust these dates. A date wrong by a day is the exact failure that breaks that promise on contact. The fix was small, an afternoon of work. Catching it was the hard part, and I only caught it because something was rigorously pretending to be a real person living far from my own clock. The least glamorous category of bug is the most dangerous one, and it hides from the maker first.

You build a tool to reduce noise, then you make it email people. Isn’t a reminder app that emails you just more noise?

It can be. That’s the real risk, and I got the first answer wrong. Email reminders shipped off by default, one per deadline, and my reasoning was restraint. Don’t email people about things they can already see on the screen.

The simulation flipped it on me, and the argument it used was clean. A casual user signs up, adds their deadlines, closes the tab, and the tool whose entire job is to remember for them does nothing at all. Then I looked at the asymmetry, and the asymmetry decides it. A missed deadline is unrecoverable and often public. Too many emails is recoverable and has an off switch. Losses weigh more than equivalent gains, which Kahneman and Tversky showed half a century ago, and the loss here is not symmetrical with the annoyance. A tool whose job is memory cannot default to silence.

So the answer to your question is that the noise is real, and the fix is not to go quiet. It’s to be quiet. One reminder, three days ahead, not a barrage. Editable per deadline, with a global off switch for the person who genuinely wants none. Present but quiet. That’s a narrow target, and missing it in either direction is easy, but silent and noisy are both worse than the narrow thing in the middle.

Say more about that. What’s the actual principle?

Silence is the worst answer a tool like this can give. A noisy tool annoys you and you turn it down. A silent tool lets the thing happen and never tells you it happened. You find out from the person you owed the work to. Between a tool that says too much and a tool that says nothing, the one that says nothing fails you exactly when failure is unrecoverable. I would rather earn the occasional eye-roll than be the reason a date passed in silence.

You deleted a feature you had already built. Walk me through that.

The browser pop-up. It was a notification that fired on screen, but only while a tab was open. I’d built it. It worked, in the narrow sense that the code did what it said.

Then I tested it under normal conditions and looked at the hit rates. These are simulated estimates from the testing, not measured numbers from real use, so hold them loosely. For the rare person who keeps the dashboard open all day, the estimate was high, around ninety-five percent. For the occasional checker it fell to somewhere in the forties to sixties. On mobile it was near zero. For anything that came due at night or over a weekend, near zero again.

Read that shape and the feature indicts itself. A reminder that mostly fires when you’re already looking at the screen, and goes silent exactly when you’ve stepped away, is not really a reminder. It’s a confirmation. And once email reminders worked with the app closed, the pop-up’s one reason to exist was gone. I could have built real push notifications to rescue it, but that’s a whole second delivery system to duplicate what email now did, with a hard ceiling on the one place that needed it most. So I deleted it. Cutting something you built, when the evidence says it fails at the moment it matters, is a design decision. It only feels like a defeat.

If email already reminds people, why also ship a weekly overview? Isn’t that two tools for one job?

I thought it might be, and then the testing convinced me they’re two jobs wearing similar clothes. The per-deadline reminder answers one question. What is about to hurt? The weekly overview answers a different one. How does my week actually look? One is the floor. It stops the catastrophe. The other is the ceiling. It delivers the feeling of seeing the whole shape at once, which is the thing people actually came for.

Every simulated persona kept the reminder when forced to choose only one, which tells you which is the floor. But the overview was the thing that turned an app I sometimes open into the thing that runs my week, especially for the person who checks in rarely. Neither replaces the other. The reminder keeps you out of the ditch. The overview is why the drive is calm. The research on notification timing points the same way. A field experiment by Fitz, Kushlev and colleagues found that people whose notifications were batched a few times a day felt better and less stressed than those getting them in real time, and notably, the group that got no notifications at all fared worse. Batched and predictable beats both the constant stream and total silence. So the overview ships, but opt-in and quiet. Off by default, sent once at the start of the week in your own local time, and skipped entirely on an empty week. The point is the shape of the week, not a flat list of it.

What was the hardest part of all this? Not the cleverest. The hardest.

Going back and forth. You make a decision, defend it to yourself, build it, and then something you set up specifically to argue with you tears it down with a better argument than you had. The pop-up was real work that I deleted. The default-off reminder was a position I held and lost. Every one of those reversals is a small admission that you were wrong, and you have to actually want that, or the whole method is theater. It is hard to keep going back and forth. But that is the work. A maker who can’t reverse themselves just ships their first instinct and calls the blind spots features.

Last one. After all of it, what is the tool actually for?

To hold the shape of your week so you don’t have to carry it in your head, and to say something useful before a date passes rather than after. That’s the whole thing. Everything I built and everything I deleted was in service of those two lines, and when a feature didn’t serve them, it left. A tool that watches your deadlines is only worth having if it speaks up while you can still do something about it. The rest is just keeping that promise and refusing to break it quietly.

You can see the result, and try it free for fourteen days, at deadlinewatch.com.

Common questions

Were the usage numbers in this interview measured from real users? No. The pop-up hit rates are simulated estimates from agent-based testing done before launch, not measured production data. They’re presented as estimates because that’s what they are. They were accurate enough to support a design decision, which was their job.

Does the email reminder send more than once? By default it sends a single reminder three days before a deadline. The timing is editable per deadline, and there’s a global off switch for anyone who wants no email at all.

Is the weekly overview the same as the reminders? No. The per-deadline reminder is a targeted nudge for one thing that’s coming due. The weekly overview is a Monday-morning read of the whole week’s shape. They answer different questions, so the tool keeps both. The overview is opt-in and skipped on weeks with nothing in them.

Who is “the maker” in this piece? The person who built Deadlinewatch, interviewed under the Conrad byline. The interview keeps them profession-neutral on purpose. The point of the conversation is the reasoning behind the tool, not a biography.

Conrad writes on deadlines, professional practice, and the design of working instruments. He still drafts on paper. He is the maker of Deadlinewatch (deadlinewatch.com).