The Architectural Reckoning: When Three Experts Agree You Should Start Over

The Architectural Reckoning: When Three Experts Agree You Should Start Over

Still June 1, 2025

There I was, knee-deep in a proof-of-concept that mostly worked, when I decided to get a second opinion. And a third. What happened next taught me something important about knowing when to stop polishing and start over.

The setup

After building a functional POC that could create GitHub issues from natural language, I found myself at that familiar crossroads every developer knows: Do I refactor this into something production-ready, or do I throw it all away and start fresh?

The POC worked. It could:

• Ingest PM documents into a vector database
• Answer questions about them
• Create GitHub issues with Claude’s help
• Even review existing tickets

But something felt off. The code was getting messier with each feature. Imports were tangled. The architecture was emerging organically rather than being designed. Classic symptoms of a POC that’s overstayed its welcome.

Getting multiple perspectives

Here’s where it gets interesting. Instead of just asking Claude Opus (my usual architectural consultant), I decided to get multiple perspectives. I asked both Claude and Gemini to review my POC and propose architectures for “Piper Morgan 1.0.”

Then — and this is the key bit — I had another Claude instance synthesize both proposals into a unified plan.

The consensus was unanimous: Start over.

The moment of clarity

“OK, so am I right in thinking that if I want to go ahead with this new synthesized plan that the other items we were discussing are effectively moot and/or will be subsumed or obviated in building ‘Piper Morgan 1.0’ (vs 0.1)?”

Claude’s response was instructive:

“YES, you’re absolutely right! The current POC served its purpose brilliantly — it proved the concept and revealed what’s needed. But pursuing the synthesized ‘Piper Morgan 1.0’ plan means…”

What followed was a comprehensive list of everything that would become irrelevant:

• Refactoring the POC
• Fixing the Sonnet vs Opus confusion in current code
• Restoring the broken Streamlit UI
• Debugging the empty knowledge base context
• That pesky milestone bug

All of it. Moot.

The architecture they all agreed on

The proposed architecture was ambitious but grounded:

User Interfaces → Conversation Layer → Intelligence Engine 
→ Execution Layer → Integration Layer → Knowledge & Learning Layer

Key principles everyone agreed on:

1. Domain-First Architecture: Start with rich PM domain models, not tool integrations
2. Event-Driven Core: Enable real-time learning and asynchronous operations
3. Plugin Everything: Every external system is a plugin from day one
4. AI-Native Design: LLMs aren’t just for text generation — they’re the reasoning engine
5. Learning-Centric: Every interaction teaches the system something

The path not taken

Claude laid out the choice beautifully:

Path A: Keep patching the POC (maybe 2–3 months before hitting a wall)
 Path B: Build Piper Morgan 1.0 right (4–6 months to surpass POC functionality)

The thing is, when three different AI systems independently tell you to start over, and their reasoning all converges on the same architectural principles, you should probably listen.

(I also ran these plans by some of my senior colleagues for a sniff test. Mostly their reaction was that it looked enterprise-grade for a hobby project and that the documentation had the sort of thoroughness only AIs have the patience for.)

The comedy begins

Of course, making the decision to start over was the easy part. Actually starting over? That’s where things got interesting.

There was that time I tried to run streamlist instead of streamlit. Classic muscle memory fail. Then I discovered my Python environment was completely borked from moving directories. "Command not found: python" despite having (venv) in my prompt.

The virtual environment was activated but pointing to the wrong Python. Hours of debugging later, I learned that moving a project with an active venv is like trying to transplant a tree by just moving the leaves.

But these little frustrations were nothing compared to what was coming.

What I did learn

Sometimes the bravest thing you can do is admit that your proof-of-concept has taught you everything it can teach you. The POC’s job was to prove the concept and reveal the challenges. It did both brilliantly.

The mistake would have been trying to evolve it into something it was never meant to be. As Claude put it: “Don’t polish a prototype when you’re building the real thing.”

The decision point

Looking back, this was the moment Piper Morgan transformed from an experiment into a real project. Not when I wrote the first line of code, not when the POC started working, but when I accepted that the POC needed to die for the platform to live.

The POC got me here. Now it was time to build the real thing.

All those tactical issues we were discussing? They just became irrelevant in the best possible way — I was building something better from the ground up.