Overengineering occurs when they want to have a perfect, future proof, scalable and modular system. The belief that "we might need this later" causes engineers to overcomplicate solutions rather than simplifying problems. But predicting the future is hard, and many of these anticipated needs may never materialize.
Overengineering software products is the norm and often happens without realizing immediately while building a tech-enabled business. It should never be primarily focused.
I was inspired by Kent Beck “Make it run Make it right”. If you make it. “Make it Run” means to have a working version of the feature or system. This often results in messy, unoptimized, or imperfect code, but it ensures progress. Then “Make it Right” is once the code is functional, refactor and improve it. By following this approach, we can deliver value quickly while maintaining long-term code quality.
It is applied when whe build tech enabled business. Build a bare minimum product that good enough to release / test it to a specific target customer. Gather feedback from real users, analyze their needs, and iterate based on actual usage rather than assumptions.
One of the key ingredients is “Make it Fast”. Meaning that A great product built too late might lose its market opportunity. Speed matters—not just in terms of performance optimization but also in how fast we build, iterate, and launch.
In the end, avoiding overengineering is not about cutting corners, but about delivering value at the right time with the right level of complexity. It’s about building just enough to test, refine, and scale as real needs arise. Ensuring that technology remains an enabler rather than a bottleneck to business growth.
So, In conclusion the First Principle is “Make it Work, Make it Right, Make it Fast In That Orders”.