Quite often clients plan to build new features on top of an old application that had been earlier iteratively developed by a dozen of different developers and you can’t be 100% sure that all of them had a chance to follow style guides or common project codebase organization. That could happen because of a tight deadline or you wasn't sure your idea is going to work and preferred to stick to a cost-effective solution.

‍

Sometimes clients believe that improving existing codebase will consume fewer resources (time and money).

‍

However the more you invest into the application that has not been properly designed for future needs - the more resources it would take to solve issues and the more it would cost to support the app.

‍

Here is a case we had in 2020-2021:

‍

The client had an application built with Ruby on Rails SaaS template and a mix of different 'out-of-the-box' solutions. He requested new features implementation, bug fixing and performance improvements.

‍

The context of this application was:

• during MVP development, some functionality was hardcoded for narrow business processes, so it was not easy to scale and expand to other markets and tasks later.
• the app was built out of ready-to-use solutions which was a perfect match for MVP. But the more users came, the more improvement requests were received. Client and previous developers tried to improve the initial MVP code, so by the time we received it for review, the app codebase had looked more like a patchwork.
• the code didn’t follow the common style. It was hard to read and understand. Bugs detection took more time than it could take in a well-organized codebase.
• frameworks and libraries versions were outdated and required updates to modern versions.

‍

So we’ve got into a situation where any updates costed too much.

‍

It was not easy for a client to find a development team ready to deal with his app support.

‍

Besides solving business problems developers care about self proficiency and skills improvement and are usually more interested to work on modern and well-organized applications. They would prefer a good example to work on.

‍

So what steps do we suggest?

‍

• Define what stage you are at: are you checking an idea, are you at the MVP stage or your product seems to be moving forward and the number of users is increasing?
• How was your MVP designed: as simple and as cheap as possible to test an idea and throw away (reasonable approach!), or its architecture was initially designed as a base for further improvements?
• Choose a team or developer you trust.
• Share the codebase and a product roadmap with them and clarify how easy it would be to build new functionality on top of existing architecture? Is it flexible? Was it designed to be scaled? Will the architecture let them provide you with high-quality solutions which are easy to support without kludges?

‍

Conclusion:

‍

If your product has passed idea validation stage and you’re ready to move forward with it then we’d highly recommend to invest also in good codebase, best practices, test coverage, modern tech stack in addition to new features development. If there is still no good codebase then it’s right time to develop it. It will certainly cost less than vast refactoring and debugging in the future.

If you are at the idea validation stage and not sure if you should invest in a product and business development, then it's okay to implement a couple more features as a kludge.

If your MVP was designed as simple as possible, and your developer did not keep in mind further updates, please don't build too much over MVP and don't wait for too long for codebase redesign if you are ready to move forward.