11 tasks. That is what it took to go from idea to a shippable content dashboard, before a single line of production code got written.
Most solo builders skip the plan phase entirely. They crack open a file, wire up the first component that comes to mind, and spend the next week untangling the mess. I have done that enough times to know exactly how it ends.
Here is what the plan covered, and why each layer exists.
Database first, always. The schema is the contract everything else depends on. Get it wrong and you are rewriting routes, frontend queries, and generator output all at once. One task: define the tables, the indices, the foreign keys. Ship nothing until this is locked.
Routes before UI. The temptation is to build the React side first because it feels like real progress. It is not. Routes are the API contract between your backend and your frontend. If you let the UI drive the route design, you end up with ad hoc endpoints that mirror component state instead of domain logic. Two or three tasks here: GET and POST handlers for drafts, a generate endpoint that shells out to the content generator, a health check.
The generator as a black box. One task that touches the generation pipeline. Keep it narrow: accept a topic, return a draft JSON blob. No UI logic, no database writes inside the generator itself. The route owns the DB call. The generator owns the generation. Separation is not elegance, it is debuggability. When things break at 2am, you want to isolate the layer in thirty seconds, not thirty minutes.
React frontend as thin as possible. Dashboards have a gravity problem: they want to grow. Every feature you could surface is a temptation. Four or five frontend tasks but constrained hard: list view, detail view, generate button, status indicator. Nothing beyond what you need to actually use the thing.
Launchd jobs as the last mile. On macOS, launchd is what keeps your background processes alive across reboots. Two tasks: one plist for the server, one for the generator tick. These are tedious to get right (plist syntax is not forgiving) but getting them wrong means the whole system evaporates after a restart. Write the plists before you declare the project shipped.
Posting job disable. The dashboard sits next to an existing content pipeline. While the dashboard is being built, you do not want the posting job firing and creating race conditions with draft state. One task: disable it cleanly and document how to re enable. Not a hack. An explicit step in the plan.,
What would I do differently?
The plan was solid but the DB schema task was underspecified. I listed it as one task when it was really three: figure out the draft state machine, define the analytics tables, decide how launchd job state gets persisted. I ended up resolving two of those mid build, which is exactly what a good plan is supposed to prevent.
The lesson is not to write fewer tasks. It is to break any task that has an "and" in it. "DB and schema and state" is three tasks. One task should do one thing. 11 was close to right. 14 would have been cleaner.
Top comments (0)