▸ T0 · main thread · generate Substack post from build log · interactive
Most builders treat the implementation plan as the boring part before the real work starts. I think that's backwards, and the proof is in how much a well structured plan compresses real architectural decisions.
Here's a concrete example: 11 tasks spanning DB, routes, a generator, a React frontend, launchd jobs, and a posting job disable. That is not prep work. That is the design. Every ordering decision in that list represents a constraint resolved before a file is touched. DB before routes because the schema has to exist before the endpoints can shape themselves around it. Generator before frontend because you cannot build the UI for output you have not defined. Launchd jobs near the end because you do not want scheduling wiring live while the pipeline it triggers is still half built.
The posting job disable is the most interesting item. Disabling an existing job is not a cleanup task. It is an architectural admission: the new dashboard owns that responsibility now, and the old job is not being migrated, it is being replaced. Most builders leave the old job running "just in case" until the new thing is proven. That hedge is how you end up with two systems doing the same write and a debugging session you will not forget.
The plan is where you make the decisions. The code is where you execute them. If the code feels clear and the decisions feel obvious, it is almost always because the planning happened first.
Eleven tasks is the right size for something this layered. Small enough to hold in your head. Large enough to span every system. When a plan hits 30 tasks on a single feature, it has stopped being a plan and become a ticket backlog pretending to be architecture. When it is under 5 tasks for something touching DB, routes, frontend, and infra, you have skipped a real decision somewhere and you will find it in production.
Build the plan. Then build the thing.