About a year ago, my team started a project at a midsize company. Leadership initially asked for a quick prototype, so I built something basic to prove the idea. They liked it, the team grew, and I even received a promotion that still feels undeserved.
The problem is that we never had time to rethink the architecture before building more features on top of it. The system has become increasingly complicated, and heavy use of AI-generated code has made the design harder to understand. Every new feature is difficult to add, and I suspect performance problems are coming, but I don't think we have the time or staffing for a complete rewrite. Some parts are so unnecessarily complex that I'm not even sure how to define the ideal refactoring plan.
The product itself hasn't been especially successful either, but development continues. I feel ashamed being responsible for it and embarrassed when explaining the system to new developers. I can't stop thinking about the project and may be heading toward burnout. I know rebuilding from scratch isn't realistic, so how should I approach the technical debt and deal with the feeling that I failed?
4 Answers
Start by communicating the problem in business terms. Document the areas that slow down development, create bugs, or could cause performance issues, and estimate the time or risk they add. Then propose an incremental modernization plan rather than asking for an unlimited rewrite.
Talk with the rest of the team first; they may be experiencing the same problems. Refactoring works best when it is broken into contained pieces with clear tests and milestones, instead of being treated as one enormous project.
A gradual replacement can work if one part of the system has a clear boundary. Design the target architecture, then migrate one workflow or component at a time while the existing system keeps running. This is safer than starting over and discovering years later that the replacement still has the same unknown requirements.
AI can help with documentation, test generation, and small mechanical changes, but don't let it perform a blind rewrite. Without tests and human review, you may just create a different codebase that nobody understands.
Please don't spend your nights rebuilding the product for free. That is a reliable way to turn technical debt into burnout. The company chose to prioritize getting a prototype working, so the company also needs to provide time and people to improve it.
Your discomfort is actually evidence that you are noticing problems and taking ownership. Most long-lived systems accumulate debt, including systems built by experienced engineers. Set reasonable boundaries, ask for dedicated maintenance capacity, and remember that a product that works imperfectly is often more valuable than a theoretically elegant system that never shipped.
This is a very common way for software to evolve. The prototype was built under a speed-first constraint, and it successfully proved enough value to become a real product. That doesn't make the resulting architecture a personal failure.
Don't aim for a total rewrite. Identify the two or three areas causing the most delivery pain or posing the greatest operational risk, then turn them into small, visible refactoring tasks. Improve code as you touch it, add tests around fragile behavior, and make each release slightly easier to maintain than the last.
That makes sense. Writing down the specific pain points would probably make the problem feel less like one huge thing and give me something concrete to bring to my manager.