Tech leaders constantly face a tough call: should we build something new or improve what we already have?
This blog provides a practical decision framework to help you know when to refactor versus when to build net-new software, based on risk, velocity, customer impact, and Logiciel’s experience in modernizing platforms.
Why This Decision Is So Hard
You’re juggling priorities:
- Speed to market
- Cost of maintenance
- Long-term scalability
- Short-term fire drills
- Internal team morale
There’s no one-size-fits-all answer, but the wrong decision creates compounding debt.
The 4-Factor Framework
Logiciel uses a 4-factor decision lens when working with product engineering teams.
1. Current System Stability
- Are there frequent outages or regressions?
- Is the bug-to-feature ratio growing over time?
If stability is poor and the code is fragile, refactoring isn’t optional. It’s urgent.
2. Team Velocity
- Do engineers avoid certain parts of the codebase?
- Does every new feature feel like a mini rewrite?
Slow delivery often signals structural problems. In these cases, refactor-first often speeds up future shipping.
3. Customer Impact
- Are end users seeing bugs, slowness, or reliability issues?
- Are complaints about performance rising?
If your customers are feeling the symptoms, they don’t care whether it’s tech debt or new features. They want things to work. Prioritize accordingly.
4. Strategic Leverage
- Does refactoring unlock speed, scale, or cost improvements?
- Is this code part of your competitive moat?
If the answer is yes, it’s worth investing in. If not, building new may be smarter.
Real-World Example: Logiciel + JobProgress
JobProgress’s backend was a monolith that resisted change. Their roadmap required new feature sets, but each addition risked breaking core logic.
Logiciel guided them through a hybrid approach:
- Incrementally decouple critical services
- Set up a modular test suite for faster QA
- Establish a refactor budget within each sprint
Results:
- Time-to-release dropped 40%
- Incidents during deployment were cut in half
- Engineers regained confidence in the codebase
When to Refactor
Choose to refactor when:
- Bugs are piling up
- Onboarding is slow due to messy code
- Feature delivery is unpredictable
- Infra or architecture causes bottlenecks
When to Build New
Choose to build new when:
- The current system no longer fits your business model
- Refactoring would take longer than replacing
- You’re entering a new market or product tier
- Architecture is fundamentally unscalable
What Most Teams Get Wrong
- They treat refactoring as “not real work”
- They wait too long and then panic-build
- They skip foundational cleanup and ship on unstable platforms
The result? Higher long-term cost and engineering burnout.
How to Communicate the Tradeoff
Use simple, high-impact language:
- “Refactoring here will reduce QA effort by 60%”
- “This rewrite will unblock 3 roadmap items stuck for 2 quarters”
- “Keeping the old system costs us $18K/month in infra waste”
Show impact. Avoid abstract debates.
Final Thought
There’s no perfect time to refactor, just more or less expensive times. Knowing when to make the call, and how to do it incrementally, can be the difference between scaling successfully or stalling out.
Logiciel helps tech companies assess, plan, and execute modernization sprints that blend building and refactoring intelligently.
Need help making the call? Talk to us.
