My codebase was documented. Tested. Deployed. My plans were fiction.
I run ConnectEngine OS as a solo founder. No team. No PM. No sprint board. Just me, Claude Code, and 16 plan documents that were supposed to tell me what to build next.
Yesterday I sat down to start the next phase of work. I opened the master plan. Phase 6 and Phase MT were listed as separate items, but they were doing the same thing. Phase 3 was marked "not started" even though I shipped it last week. Two phases had dependencies on work that was already done. One had a status line from three weeks ago that was never updated.
The code was accurate. AGENTS.md (my living reference file) was accurate. The rot was in the plans themselves.
Plans Have No CI
Code has linters, type checkers, tests, deployment pipelines. If something breaks, you know. Plans have nothing. Nobody runs plan lint before a sprint. Nobody diffs the plan against the codebase to check if what the plan describes still matches reality.
So plans drift. Quietly. A status line goes stale. A dependency resolves but nobody updates the blocker list. Two documents describe overlapping work because they were written a month apart and nobody cross-referenced them.
I wrote about the unsexy infrastructure behind AI agents a few weeks ago. RLS policies. Tenant isolation. Error recovery at 2am. That post was about the code nobody sees. This one is about the documents nobody reads.
The Method: Ground Truth First, Rewrite Second
I did not open the plans and start editing. That is the trap. If you read a stale plan, your brain anchors to what the plan says, not what the system actually looks like.
Instead I ran a research pass first. I had Claude Code dump the current state of the entire system: 85 API routes. 49 database tables. 24 security functions. 15 active workflows. 16 plan files. All in one inventory, grounded against the actual codebase. Not from memory. Not from last week's session notes. From the code.
Then I read every plan against that inventory. One by one. Sequentially, not in parallel. That was a deliberate choice. When you read Plan A right before Plan B, you notice the overlap. You catch the merge opportunity. If you read them in parallel, you only discover the conflict at the end.
What I Found
16 plans. 3 merge decisions emerged organically:
Phase 6 (credential management) and Phase MT (notification channels) were doing the same work on the same database pattern. Merged them. Saves a full session of duplicated scaffolding.
A multi-tenant audit document had 16 items. 10 of them were already tracked in other phases. Split it: fold the duplicates into their owner phases, keep the residual 6 as a pre-launch checklist.
A security bug that was being treated as a standalone fix belonged inside the merged phase. Moved it there.
Result: one commit. 22 files changed. +893 lines, -288 lines. One canonical priority list that every future session reads as the source of truth.
The codebase had zero ground-truth discrepancies. The plans had dozens.
Why This Matters If You Are a Solo Founder
If you have a team, plans get challenged. Someone in standup says "wait, didn't we already ship that?" and the plan gets updated. A PM notices the overlap because reviewing plans is their job.
Solo founders do not get that. Your plans only get reviewed when you read them. And you only read them when you need to know what to build next. By then they are stale.
I built my AI agent inside n8n specifically because I needed a system that could do the work I used to delegate to a team. The same principle applies here. If nobody is going to review your plans for you, build a process that forces the review.
My process now: before rewriting any plan, dump the current system state first. Compare the plan against facts, not memory. Read sequentially so merge opportunities surface naturally. One commit per rewrite session so the diff tells the story.
The Uncomfortable Truth
I had been making decisions based on plans that described a system from three weeks ago. Not the system I had today. Every time I opened a plan and saw "Phase 3: not started," I mentally prioritized it. But it was already running in production.
If you are building alone, your plans are the closest thing you have to a second brain. And if that brain is running on stale data, every decision downstream is slightly wrong.
When did you last read your own roadmap from scratch? Not a glance. A full read, plan by plan, against what your system actually looks like today.
If the answer is "I don't remember," you have the same problem I had yesterday.
I keep a running log of infrastructure decisions and production lessons, including the security ones that keep me up at night. The plan rewrite was the first time I applied the same rigor to the plans themselves. It will not be the last.
Tobias
Top comments (0)