I understand from where you are coming from and it is true that every line of code solves some business use case.

A “messy” codebase can potentially multiply the number of incidents a team sees and the amount of time spent on fixing the issue. In most startups, after a couple of years, the developer who wrote the code is usually no longer around. In addition to that, documentation is usually sparse, which makes code readability very important.

It's very important to avoid code smells and have a pristine codebase. Refactoring is a continuous exercise and every developer should master the art of refactoring. If you look back at your code after a month, you might find it messy as during that time you would have surely learned things to do it in a better way. If the team decides to take up refactoring and improve code’s quality, it can surely be achieved. Our team has learned the importance of a clean codebase and TDD the hard way and now with everything at stake, improving the codebase is our highest priority.

SOLID principles can serve as thumb rules while writing code. Solid design principles must be followed for good design like:

• S — Single-responsibility principle
• O — The open-closed principle
• L — Liskov substitution principle
• I — Interface segregation principle
• D — Dependency Inversion Principle