About a year ago, my team started building a project at a midsize company. Leadership originally asked for a quick prototype, so I put together something basic. They liked it, the team grew, and I was even promoted to lead the project. The problem is that we never had time to redesign the architecture before building more features on top of it.
Now the codebase is increasingly difficult to understand and extend. Some parts are unnecessarily complex, and heavy use of AI-generated code has made the situation worse. I'm also concerned that the current architecture will eventually cause performance problems, but I don't think we have enough time or staff for a major rewrite. I'm not even sure how to define the complete refactoring plan because the system has become so tangled.
The product itself hasn't been especially successful either, but development continues. I feel embarrassed when explaining the project to new developers and worry that I'm a fraud for being responsible for it. I'm also starting to feel burned out and can't stop thinking about the project. I wish I could rebuild it from scratch, but that obviously isn't realistic. How would you approach this situation?
4 Answers
Start by communicating the problem clearly to your manager and the rest of the team. Document the specific issues: time lost while developing features, fragile areas, likely performance bottlenecks, and the risks of leaving them untouched. Translate technical debt into delivery time, bugs, and business impact rather than simply calling the architecture bad.
Then create a realistic modernization plan with small, contained steps. Choose one important boundary or workflow, improve it, and make each release slightly safer and easier to maintain. You can also leave concise notes explaining why particularly messy sections exist and what a better future design might look like.
Please don’t fix this by spending your nights and weekends doing unpaid work. That’s a fast route to deeper burnout, and structural technical debt needs company time and agreement. Your promotion is evidence that the project created value, not proof that you deceived anyone.
The fact that you’re uncomfortable with the current state probably means you’ve learned enough to recognize problems you couldn’t have anticipated when the project was just a prototype. Software is full of trade-offs, and good engineers regularly inherit systems they would design differently today.
A parallel replacement can work in some cases, but it should be treated as a carefully scoped product rather than an exciting chance to start over. Keep the existing system running, build only the most valuable pieces of the replacement, and migrate functionality gradually. A complete rewrite can take years and often recreates the same problems if the underlying requirements and processes haven’t changed.
If AI is used during the refactor, use it for analysis, test generation, small transformations, and documentation. Don’t let it blindly rewrite the entire codebase. Without strong tests and human review, you may end up with a different mess that nobody understands.
First, don’t treat this as a personal failure. A prototype becoming production software is extremely common, especially when the business prioritizes speed. The prototype achieved its original goal, and the problems only became obvious after the project grew.
Avoid proposing a giant rewrite unless you have no other option. Identify the two or three areas causing the most pain or risk, add tests around them where possible, and improve them incrementally while working on related features. A small amount of cleanup every sprint can gradually make the system much healthier.
That’s a helpful way to look at it. I’ve been treating the architecture as something I personally failed at, instead of recognizing that the requirements and constraints changed after the prototype succeeded.