Two days into building Founder OS as a solo founder, I had a beautiful architecture diagram, a 7-phase build pipeline, and zero working code. The agents were running. The architecture was clean. And it was completely wrong.
This is what it looks like to build in public — the day I hit delete on everything, and why that moment was the actual starting line.
Key Takeaways
- 78% of software projects experience scope creep, often from over-engineering before validating (Electroiq, 2026)
- Deleting a day's work and starting incremental led to 30 AI plugins shipped in 6 days
- AI tools amplify whatever approach you take, including the wrong one
- Three out of four successful startups didn't succeed with their first idea (WinSavvy, 2026)
What Does It Look Like When Everything's Going Wrong?
Over a third of new ventures in 2026 are solo-founded (Carta Solo Founders Report, 2025). That means more people than ever are building alone, making architecture decisions with no one to push back. I was one of them.
The plan looked bulletproof on paper. Build 30 AI plugins simultaneously using parallel sub-agents. Each plugin would follow a 7-task chain: Scaffold, Skills, Commands, Testing, Docs, Blog, Gift. Phase 0 for infrastructure. Phases 1 through 5 running in sequence. Cross-plugin parallelization. Within-plugin task chains. Batch-by-phase execution.
I'd set up CLAUDE.md and AGENTS.md with a multi-phase workflow that could spawn dozens of agents at once. It felt like directing an orchestra. The kind of system you'd diagram on a whiteboard and feel smart about.
Here's the thing nobody tells you about over-engineering: it doesn't feel like a mistake while you're doing it. It feels like thoroughness. It feels productive.
The output? Tangled code. Agents stepping on each other's state. Not a single plugin that could be tested in isolation. Every piece depended on every other piece, and none of them worked.
Why Do Solo Founders Over-Engineer?
78% of software projects experience scope creep (Electroiq, 2026). But scope creep isn't always feature requests from clients. Sometimes it's you, alone at midnight, adding another abstraction layer because it "might be useful later."
Over-engineering isn't about complexity. It's about building before you've validated the pattern.
When you're a solo founder, there's no tech lead asking "do we actually need this?" No CTO saying "ship the simple version first." You're the architect, the developer, the QA team, and the product manager. Every idea gets a yes, because there's no one to say no.
And then there's the sunk cost trap. Research on the sunk cost fallacy shows that cognitive biases systematically reduce investment project efficiency, with sunk costs being the most influential factor (PMC, 2020). The more sophisticated your architecture, the harder it is to walk away from it. You've invested hours. The diagrams are beautiful. Surely you can make it work if you just push a little harder?
You can't. Not always.
The AI Over-Engineering Trap
Here's what makes 2026 different from any other year to over-engineer a project. AI coding tools now write 41% of all code (Index.dev, 2026). That's not a typo. Nearly half.
A randomized controlled trial by METR found that experienced developers using AI tools actually took 19% longer to complete tasks, despite believing they were faster (METR, 2025). When Claude Code can scaffold an entire multi-agent pipeline in minutes, the gap between "I had this idea" and "I have 2,000 lines of code" collapses to nothing. You skip the "should I?" question entirely. The code exists before you've decided whether it should.
And 66% of developers say the biggest issue with AI-generated code is that it looks almost right but fails in testing (Index.dev, 2026). It passes the "looks right" test, which means you don't question the approach. You question the implementation. You debug the wrong layer.
Speed of generation doesn't equal speed of validation.
What Did the "Elegant" Architecture Actually Look Like?
Here's what I actually built on day one. The config files defined a waterfall of dependencies:
# The original AGENTS.md approach (simplified)
phases:
phase-0: # Infrastructure - blocks EVERYTHING
tasks: [templates, mcp-config, shared-skills]
blocks: [phase-1, phase-2, phase-3, phase-4, phase-5]
phase-1: # Priority plugins - 5 at once
plugins: [inbox-zero, client-context, report-gen, invoice, sow]
per_plugin_chain:
- scaffold -> skills -> commands -> testing -> docs -> blog -> gift
parallelization: cross-plugin # All 5 build simultaneously
phase-2 through phase-5: # Remaining 25 plugins...
# Same pattern, same chain, same parallelizationEach plugin spawned its own sub-agent. Each sub-agent tried to follow the 7-task chain. Phase 0 had to complete before anything else could start, which meant one bottleneck controlled the entire project.
The parallelization strategy had three layers: within-plugin (tasks in sequence), cross-plugin (multiple plugins building at once), and batch-by-phase (groups releasing in waves). It was a marvel of project management theory.
In practice? Five sub-agents tried to write to the same template directory. Skills written for Plugin A referenced infrastructure that Plugin B was still building. Testing couldn't run because the shared MCP configuration wasn't stable. Three agents were modifying it simultaneously.
I spent an entire day resolving conflicts between agents that were all technically doing the right thing in the wrong order.
What Does It Take to Hit Delete on a Day's Work?
Commit e20d0a4: "Fresh start: clean up plugins and backlog, build one by one."
That's what deleting everything looks like in git. One line. The hardest line I've written.
The code worked, technically. The agents ran. The architecture diagram was clean. But clean architecture that produces tangled output isn't clean. It's a lie you tell yourself about the mess underneath.
Here's what I kept and what I deleted:
The foundation stayed. The implementation went. That distinction matters. I didn't lose the learning from day one. I lost the code that came from the wrong approach to applying that learning.
The Emotional Cost of Deleting Code
Nobody talks about how it actually feels to type git add . && git commit -m "burn it down" and mean it.
It feels like failure. Full stop. You spent an entire day building something. You told yourself it was good. You watched the agents run and felt the momentum. And now you're looking at a commit message that says "Fresh start" and wondering if you just wasted the only productive day you had this week.
The sunk cost pull is physical. Your chest tightens. Your brain runs a highlight reel of the clever parts. That parallelization logic was elegant. The phase dependency graph was genuinely smart. Surely you can salvage something?
Here's how I knew I was making the right call instead of rage-quitting: I could articulate exactly what was wrong. Not "this is frustrating" or "I'm stuck." I could say, specifically, that the architecture created coupling between plugins that made isolated testing impossible. That the parallel agent strategy produced race conditions in shared state. That the 7-task chain per plugin was a theoretical ideal that broke on contact with reality.
If you can name the structural problem, starting over is a decision. If you can only name the emotion, it's a reaction. That difference matters. Rage-quitting sounds like "this is stupid and nothing works." A real reset sounds like "the approach is fundamentally wrong, and fixing it would take longer than rebuilding."
I sat with the decision for about thirty minutes. Reread the code. Tried to imagine patching it. Every fix I considered would add another layer of complexity to a system already drowning in complexity. The answer was obvious. It just wasn't easy.
Three out of four successful startups didn't succeed with their first idea (WinSavvy, 2026). The pivot isn't the failure. Refusing to pivot is.
What Did the Rebuild Look Like?
The new strategy was embarrassingly simple. Build one plugin. Make it work. Then build the next one.
No parallel agents. No 7-task chains. No phases. Just: pick a plugin, write a spec, build it, test it, ship it.
Plugin #01 was Inbox Zero Commander. A Pipeline pattern with 4 agents: Triage, Action, Response, Archive. Two modes: a fast single-agent summary and a full --team pipeline. Ten integration test scenarios covering the complete lifecycle.
It worked on the first pass. Not because I'm a better developer than I was the day before, but because I could see the whole thing. No hidden dependencies. No agent conflicts. One plugin. One test suite. One outcome.
Then I did something that changed the trajectory of the entire project. I turned the process into two commands: /plan-plugin and /build-plugin.
/plan-plugin took a namespace name and generated the full specification: directory structure, skill files, command definitions, agent roles, and integration test scenarios. Everything Plugin #01 needed, templated so the next plugin could spin up in minutes instead of hours.
/build-plugin consumed that spec and produced a working plugin. Scaffold the directories. Write the skills. Wire up the commands. Run the tests. One command, one plugin, one outcome.
The moment Plugin #02 (Daily Briefing) passed all its integration tests on the first run, I knew the factory worked. Not because the code was perfect. Because the process was repeatable. The pattern that worked for Plugin #01 became a repeatable factory.
The Factory That Built 30 Plugins
Once the factory existed, every plugin followed the same lifecycle: Notion spec, /plan-plugin, beads backlog, /build-plugin, skills and commands, integration tests, documentation.
The 24th plugin shipped as smoothly as the 2nd. That's the power of validating one before building thirty. The whole story of how that factory produced 30 plugins in 6 days is its own post.
Zero. Zero. Zero. That's what the "elegant" parallel approach produced. The incremental approach (build one, validate, repeat) produced everything.
How Do You Know When to Start Over?
Only 35% of projects worldwide finish successfully, according to the Standish Group's CHAOS research (Standish Group, 2024). Two-thirds of projects fail. The question isn't whether your project will hit a wall. It's whether you'll recognize the wall when you hit it.
The signal wasn't a failing test or a crash. It was the growing distance between how impressive the architecture sounded and how little it actually did. Here are three warning signs I missed until it was almost too late:
You're solving meta-problems instead of real problems. I spent hours designing the agent orchestration system. Not one of those hours produced a working email triage, a functioning CRM sync, or a single invoice processor. I was building the system that builds the system that builds the thing. That's two layers too many.
You can't test a single unit in isolation. If testing one plugin requires running the entire infrastructure layer, three other plugins, and a specific build phase, you don't have a modular system. You have a monolith pretending to be modular.
You're explaining the architecture more than using it. When I caught myself spending 20 minutes describing the parallelization strategy to Claude Code instead of just building a plugin, the ratio was wrong. If the explanation is longer than the implementation, start over.
According to a 2026 analysis of AI-assisted development, 45.2% of developers say debugging AI-generated code takes longer than debugging human-written code (Index.dev, 2026). AI doesn't just generate code faster. It generates wrong code faster, too. The architecture pivot that came later was a direct descendant of this lesson: simplify ruthlessly, or complexity will bury you.
What Would I Tell a Founder Starting a Build Today?
52.3% of companies with successful exits were started by solo founders (Scalable.news, 2026). More than half. You don't need a co-founder to build something real. But you do need the discipline to throw away bad work fast.
Three rules I'd carve into every solo founder's desk:
Build one before you build thirty. Don't parallelize until you've serialized. The pattern you think will work at scale might not work at all. Prove it with a single unit first. My first plugin took a few hours to build properly. The remaining 29 took the same amount of time combined, because the factory was validated.
Delete faster. The code you keep from a failed approach is usually the wrong code to keep. I saved templates and infrastructure. I deleted every line of implementation. The foundation was reusable. The implementation wasn't. Know the difference.
Your AI tools are force multipliers, not wisdom multipliers. 84% of developers now use AI tools (Index.dev, 2026). But force multiplied by the wrong direction is still the wrong direction. AI didn't cause my over-engineering. It just helped me over-engineer at unprecedented speed.
The counterintuitive truth? Starting over was the fastest path to shipping. The day I deleted everything was the day 30 plugins, 4 pillars, and 82 commands became possible.
Ready to build incrementally instead of over-engineering?
npx founder-os@latest --initIt's free. Open source. MIT license. One command to install. Start with a single plugin and let the factory prove itself.
Or if you want someone to build custom AI automations for your business, book a call with NaluForge.
About the author: Lukas Halicki is the founder of NaluForge, building AI automation tools for solo founders and small teams. He built Founder OS, an AI chief of staff running inside Claude Code, from first commit to 30 shipped plugins in 6 days.
Frequently Asked Questions
How do you know if you're over-engineering?
If your architecture diagram is more impressive than your working demo, you're over-engineering. The clearest signal: you're solving problems your users haven't encountered yet. With 78% of projects suffering scope creep (Electroiq, 2026), this isn't rare. Ask yourself: can I test one unit in isolation right now? If the answer is no, simplify.
Is it ever wrong to start over?
Yes — if you haven't identified why the first approach failed. A rewrite without learning is the same mistake with a fresh git history. Three out of four successful startups pivoted (WinSavvy, 2026), but they pivoted with insight, not just frustration. I kept my templates and infrastructure for a reason: the foundation was sound. The implementation wasn't.
How do you build in public when things go wrong?
The failures are the content. "I deleted everything and shipped 30x faster" is a more compelling story than "everything worked first try." Roughly 90% of startups fail (Failory, 2026), and the ones that share their struggles build stronger audiences than the ones that only share wins. Your audience isn't looking for perfection. They're looking for honesty about what actually works.
Can AI tools help avoid over-engineering?
AI tools amplify whatever approach you take. If your approach is wrong, AI helps you build the wrong thing faster. In fact, 66% of developers say AI suggestions look right but fail testing (Index.dev, 2026). Use AI to accelerate a validated pattern, not to generate an unvalidated architecture. Validate first. Then let the machines multiply.
What Building in Public Actually Looks Like
The day I deleted everything wasn't a setback. It was the starting line.
Over-engineering is building before validating. AI tools make it easier to fall into that trap because they close the gap between idea and code so fast that you skip the "is this the right idea?" step entirely. The second approach always ships faster, because it carries the learning from the first.
If you're a solo founder staring at an architecture that's beautiful but broken, here's your permission to hit delete. Keep the foundation. Lose the implementation. Build one thing. Make it work.
Then build the factory that builds the rest. That's exactly what I did, and it's how Founder OS went from zero to 33 namespaces and 82+ commands in less than a week.