Eleven tasks from nothing to shipped

Eleven tasks. That is the full scope of a working content dashboard: schema, API routes, generation endpoint, React frontend, background jobs, and a kill switch on the old posting job. Written down in a git commit message before a single line of code existed.

That is the part most people skip.

I do this on every nontrivial build now. The plan is not for project managers or ticket trackers. It is for me, so I can sit down on day three and know exactly what to touch without re deriving the whole architecture from memory.

The breakdown on this one: DB schema first, then server routes, then the generation endpoint, then React frontend, then launchd jobs, then disabling the old posting job that the dashboard would replace. That order is not arbitrary.

DB first because every downstream decision depends on what the schema looks like. If you build the React components before you know what shape the data takes, you will rebuild them. Routes second because they are cheap to add once the schema is stable and define the contract the frontend consumes. Generator endpoint third because it is the highest value feature and you want it working before you invest in polish. Frontend fourth, after you can actually call real endpoints. Jobs fifth, because you need the frontend proving out before you add orchestration around it. Kill switch last, because disabling the thing the dashboard replaces is irreversible and should happen only when the replacement is proven.

The common mistake is inverting this. Build the UI first because it is the most visible thing. Ship the frontend skeleton, wire it to a fake endpoint, then scramble to backfill the real logic. This produces demos that look finished and backends that are not. I have done it. The demo fools you into thinking you are done.

The other mistake is not writing the plan at all. Treating it as overhead. Experienced engineers are supposed to just know what to do, so writing it down feels like justifying yourself to a product manager. That is the wrong frame. The plan is not accountability theater. It is a context compression tool. Eleven items in a commit message costs ten minutes and saves three hours of staring at the screen wondering what the next logical step is.

On what I would do differently: the plan had no time estimates and no explicit dependency ordering. It was a flat list. That works for a solo build where you hold the whole context. It would fall apart with two people. Next time I do a build this size with anyone else touching it, I will add explicit blockers between tasks so the order is stated, not implicit. “Route setup blocks generation endpoint” should be in the plan text, not just in my head.

Eleven tasks, shipped. The plan was the first commit. That is the move.