It is hard to go back and forth. That is the work.

# It is hard to go back and forth. That is the work.

The unglamorous truth about building a useful tool is that you spend most of the time undoing decisions you already made. Not because the first decision was careless. Because the first decision was a guess, and guesses need checking, and checking them means going back to a thing you had already crossed off and crossing it back on. That motion feels like failure while you’re doing it. It is actually the whole job.

I built a deadline tool alone, with no users yet. The plan, when I started, looked clean. A reasonable set of features, a reasonable order to build them in, a reasonable idea of what each one was for. I want to tell you how much of that plan survived contact with its own testing, because the honest answer is the most useful thing I learned.

Not much of it survived. And the surviving part isn’t the point. The reversals are the point.

The reminder I shipped off by default

The first decision I had to take back was about silence. Email reminders shipped off by default, one per deadline, and I had a tidy argument for it. Don’t email people about things they can already see on a screen. Restraint. It felt mature.

Then I put the product in front of evaluators built to use it the way real people would, and one of them walked the obvious path. A casual user signs up, adds their deadlines, closes the tab, and the tool whose entire job is to remember does nothing. I had optimized for the person who lives in the app. Almost nobody lives in the app.

So I turned the default around. On, but quiet. A single reminder a few days ahead, editable, with an off switch for anyone who wants none. That reversal took an afternoon to build and a week to admit. The admitting is the slow part. You don’t just change a setting. You change a position you’d defended to yourself, and the new position is the one you’d argued against last month.

The feature I built and then deleted

The harder reversal was a feature I’d already finished. A browser pop-up reminder, an on-screen notification that fired while a tab was open. I liked it. It worked, in the narrow sense that the code did what the code promised.

Then I tested it under normal conditions and looked at how often it would actually reach someone. 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 ran high. For the occasional checker it fell toward half. On a phone it was near zero. For anything coming due at night or over a weekend, near zero again.

Read that shape and the feature argues against itself. A reminder that mostly fires when you’re already looking, and goes quiet exactly when you’ve stepped away, isn’t a reminder. So I deleted work I was proud of. That is a strange afternoon. Nothing in the build process prepares you for the specific feeling of removing a thing you got right, because it turned out to be the wrong thing to have gotten right. It reads as a loss in the moment. It was the correct call, and the two facts sit in the same room and don’t cancel out.

The setting that got scattered, then pulled back

The third reversal was quieter and more typical, which is why it’s worth naming. It was about where a control should live.

Under any pressure to make a feature feel important, the instinct is to put its setting everywhere. On the form where you create the item. On a settings page. On the item itself. In a detail panel behind a click. Each placement feels like care. Together they feel like a maze. I scattered a reminder control across four surfaces before I noticed I’d built a small scavenger hunt and called it flexibility.

Pulling it back to one obvious place was, again, undoing my own work. Set things up where you make them, change them where you act on them, and keep the rest in a single place a person can find without a map. Simplicity there wasn’t the absence of capability. It was the refusal to make someone hunt for it. But I only got there by building the busy version first and disliking it honestly.

Why the first plan is reliably wrong

Here’s the part that took the sting out, once I understood it. The back-and-forth isn’t a sign you planned badly. It’s structural.

Buehler, Griffin and Ross gave the effect its name in 1994, studying how people estimate their own work. We underestimate how long our own tasks will take, reliably, even when we have a long history of being wrong about exactly this. Knowing you’ve misjudged before doesn’t fix the next estimate. The bias lives below the level where knowing helps. Their work was about time, but the same blind spot applies to design. Your first read of what a feature is for, and whether it works, is an estimate made from inside your own head, by the one person least able to see around it.

Which means the first plan being wrong isn’t a personal failing to feel bad about. It’s the expected output of a single mind guessing about strangers. The plan was never going to be right. It was going to be a starting position, and the work was always going to be the distance between that position and a tested one. If you accept that going in, the reversals stop feeling like proof you’re bad at this. They start feeling like the method doing what it’s for.

That doesn’t make them pleasant. Each one is a small admission that the version of you from three weeks ago was confident and wrong. You have to actually want that, or you’ll defend the first guess to protect the feeling of having been right, and the tool will quietly carry your blind spots as features. The makers who can’t reverse themselves don’t build worse plans. They just ship the first one.

I won’t dress this up. Deadlines are not an easy thing to build a tool around, because the thing you’re protecting people from is the exact thing you keep getting wrong about yourself. The work is slow for an honest reason. Most of it is the going back. The going back is not the part before the work. It is the work.

You can try the result free for fourteen days at deadlinewatch.com.

Common questions

Isn’t all this back-and-forth just bad planning up front? No, and the research says so. Buehler, Griffin and Ross documented in 1994 that people underestimate their own tasks even when they know they’ve been wrong before. A first plan made by one person is a guess from inside the one head that can’t see its own blind spots. The revising isn’t a failure to plan. It’s how a guess becomes a tested decision.

Were the pop-up usage numbers measured from real users? No. They’re simulated estimates from agent-based testing done before launch, not measured production data. They were specific enough to support a decision, which was their job, but they’re estimates and the piece treats them as such.

Why delete a feature you’d already finished building? Because finished and useful are different things. The browser pop-up worked, but it mostly reached people who were already looking at the screen and went silent when they weren’t. Once email reminders covered the same job with the app closed, keeping the pop-up meant maintaining a weaker version of something already solved. Removing it was the cleaner call.

Who is “the maker” here? The person who built Deadlinewatch, writing in the first person under the Conrad byline. The reflection stays profession-neutral on purpose. The reasoning is the point, 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).