Tooling Before Signal Is Procrastination With a Commit History
I wrote a rule into a ninety-day plan this week and I want it on the record before I talk myself out of it:
I wrote a rule into a ninety-day plan this week and I want it on the record before I talk myself out of it:
No custom software before week four.
The plan is a content and outreach programme — one piece a week, each sent directly to a named list of people, tracked in a log of attempts rather than outcomes. The entire thing runs on a spreadsheet. Twelve rows, a handful of columns. It would take me most of a day to build a tool that does it properly, and I have deliberately forbidden myself from doing that for a month.
Why the rule has to exist
Because building is the most convincing form of avoidance available to me.
Sending the first message to a named person is exposure. It can be ignored. Building the system that will one day track the messages is safe, productive-feeling, and produces a visible artefact at the end of the day. Both fill the same afternoon. Only one of them can fail publicly, and I will choose the other one every time unless something stops me.
This is not a motivation problem and I've stopped treating it as one. It's that the two activities are indistinguishable from the inside. Both feel like work on the project. Both produce something. At the end of a day spent building tooling I can point at the tool, and nothing about the day tells me that the project didn't move.
The spreadsheet does something the tool can't
The stronger half of the argument isn't about discipline, though. It's that the manual version is doing real work that I'd lose by automating early.
Running a process by hand is how you find out what the process actually is. Three weeks of a spreadsheet will tell me which columns I never fill in, which step I keep doing differently, which field I wish existed. A tool built in week one encodes my guess about all of that — and then I'll be reluctant to change it, because it's built, and now the guess has sunk cost defending it.
So the rule isn't really "don't build for four weeks." It's don't build until the manual version has produced enough signal to specify the tool. Four weeks is a proxy for signal, because signal is hard to declare and a date isn't.
The other half: specificity is what makes a plan run
The same week, I noticed why this plan feels different from the ones I've abandoned. It isn't a better idea. It's that it's dated and counted: twelve pieces, seventy-one named contacts sorted into six lanes, a first shipment on a specific date, and gates at day forty-five and day ninety with a number attached to each.
None of that is clever. All of it is checkable, which is the point. A plan that says "publish consistently and build an audience" cannot be failed, and a plan that cannot be failed cannot be executed either — there's no state it can be in on a Tuesday that tells you whether to act.
The two rules are the same rule from different ends. Specificity makes a plan executable; premature tooling makes it postponable. One gives you something to check against today, the other gives you something to build instead of checking.
Where this goes wrong
Two honest objections.
Some manual processes are painful enough that you never start. If step one of the loop is twenty minutes of copy-paste, the rule that forbids fixing it is the reason the loop dies in week two. The gate should be signal, not stoicism — and if the manual version is what's stopping the work from happening at all, that is the signal, arriving early. Build the thing. Just be able to say which specific friction you're removing, because "it would be cleaner" is not a friction.
And the rule is trivially gameable by someone with my instincts. I can spend a week not writing software and instead writing a plan, a framework, a skill definition, a document about how the process will work. That's the same avoidance in a different file extension, and it doesn't trip the rule at all. I've caught myself doing versions of this before and written it down each time, which is itself an instance of the pattern.
The only test I trust: at the end of the day, did something leave the building? A message sent, a piece published, a call booked. If nothing did, it doesn't matter how much was produced — and it especially doesn't matter that what was produced was good.