Startups come face to face with the rewrite question quite early in their journey. Building an MVP, releasing it in the market to assess user reactions to iterate and identify areas of improvement and create a stronger product is the startup way. In this journey, startups pivot multiple times and make subtle and dramatic changes in the code, the technology, and the utility they offer. What they often end up doing is adding patches that enable the functionality requirements of the hour. This patch on patch method works -to a point. Almost inevitably, the startup then realizes that they have built a house of cards that is being held up only by their prayers.

So then, how do you realize that the product in question needs a rewrite? In a previous blog, I addressed the subject of a product rewrite in the context of legacy technologies. Given that startups work with the brightest shiny new technology, the legacy aspect is absent. What then, would be the other factors that growth-mode startups must take into consideration to assess if the product needs a rewrite?

The pivot complex –

Startups often pivot and quickly. Doing so is necessary. However, this often creates a mound of unnecessary, complicated code. You might even end up with the wrong architecture to support the needs of the current product that you are on the road to developing. With mountains of complex code, it will become harder to add the new functionalities and features necessary to keep the user attached to the product. As the needs of the user change often in the lifetime of the software, startups must ensure that their basic foundation is strong enough to enable this change. If not, then it is time to consider a product rewrite to provide that the product is future-ready.

Change in product direction –

As the startup journey progresses, they are in better condition to create an evolutionary roadmap for their MVP and turn it into a completely functional product. In this journey, the product itself might evolve and might need an entirely new direction. In case of such a product evolution, startups have to assess the existing capabilities of the product and take an objective decision if the current product architecture can capably support that move. As an example, you might have built a desktop application, but if the users now demand the same product as a mobile app which has to be enabled. Alternatively, in some cases, a business application might need to evolve into a comprehensive platform or move into a different product vertical altogether. When the product direction changes, it becomes imperative to examine the current product status and see if the front end and backend can support the demands of the new avatar.

Technical Debt –

Just like how accumulated financial debt can sink your life goals, the accumulated technical debt can sink a product. A certain amount of technical debt, especially for growth mode startups is standard in the time-constrained push for success. However, if technical debt is not repaid much like financial debt, it will keep accumulating ‘interest.’ This debt will only make it consistently harder to add changes and iterate the product according to the user and business needs. As the ideas gain traction, the accumulated technical debt is refactored once you’ve reached the scalability threshold. If it is not possible, then a product rewrite becomes a necessity.

Inadequate testing –

The absence of adequate testing can sound the death knell in a performance-driven world. Testing has to be at the heart of product development today. However, with an MVP, most startups do not focus on testing as much. After all, the need is just that of a functional product to assess the market acceptance. However, what happens when you keep adding functionalities and features to such a product? Eventually, you might create a complete product but one that will be prone to errors and bugs. Will the product survive? Will it be easy to test such a product then? Will it still serve the needs of the users if testing the product takes longer than usual? It then makes sense to examine if the product in question can withstand the test of time. Assess if all the code will continue to work in increased loads. Identify what could go wrong. If you cannot thoroughly test a product and cannot add testing into the future, and if test automation initiatives are failing because of the product complexity it might be time to consider a rewrite.

Functionality, scalability, and maintainability –

The importance of product functionality, scalability, and maintainability are almost impossible to quantify. These factors are so only because the cost impact of these is directly related to the longevity of the product. If a software product cannot respond to the needs of the users, then it is already DOA which usually happens when the base code becomes so complicated, that scaling the product, adding new functionalities, and maintaining the product to fix defects, etc. become prohibitively time consuming and resource-intensive. If the software is unmanageable, is hard for the current team to understand, has become fragile over time owing to the patch on patch approach or if it seems that doing things right is harder than doing things wrong, then the time for a rewrite has come.

The decision to rewrite has to be carefully taken and done for the right reasons. As the product begins to mature, startups must evaluate if the rewrite is going to help them move the product, and consequently the organization, forward. Organizations must adopt the appropriate strategy to future-proof their products. Also, if that demands a rewrite, then that’s the way the cookie should crumble.

This blog was originally published on Linkedin Go to blog