the greenfield temptation

ECHO serves 100+ organizations in 9 countries. Built under “move fast and break things.” The codebase shows it. My gut said greenfield. Start fresh. Use the critical core functionality and build a clean system around it.

That gut was wrong, and I needed someone to push back hard enough for me to see it.

How tightly coupled is your core to the current framework? I’d been claiming the core transcription and analysis engine was independent. If that’s true, greenfield loses its primary justification. You don’t need to rebuild the house to rewire the electricity if the walls aren’t load-bearing.

What specific patterns does the current architecture make impossible? I wanted event-driven architecture. But wanting EDA and proving the current system can’t support EDA are different claims. Hadn’t done the analysis. And it turned out I could implement event-driven patterns incrementally on the existing codebase.

What’s the customer cost? We have paying customers at scale. Greenfield typically means feature freeze during rebuild. For a startup that needs to raise 1-2M euros in three months, telling customers “we’re rebuilding, sit tight” is a business risk I hadn’t quantified.

Is the technical debt actually blocking you, or do you just want clean code? This one stung. There’s a real difference between “this debt prevents us from shipping features customers need” and “I’m embarrassed by this code.” Both are valid feelings. Only one justifies a rewrite.

So: map current architecture dependencies. Identify which parts are genuinely coupled vs assumed coupled. Prototype event-driven patterns on existing codebase. Measure complexity vs greenfield timeline. Calculate customer impact.

What I found: core functionality was more decoupled than expected. Event-driven migration could happen incrementally, which it eventually did with the Dramatiq-to-EDA work. Customer-facing features kept shipping. No freeze required.

“My intuition tells me we should greenfield” is not a strategy. It’s a preference dressed up as analysis. Define the specific constraints you’re hitting, prove they can’t be solved incrementally, quantify the cost of both paths, then decide.

ECHO will probably need significant architectural rework eventually. But “eventually” and “right now during a funding crunch” are very different timelines.