Whether we’re speaking to early-stage startups or senior VPs and CEOs at big organizations, a statement that we hear again and again goes something like this:
“We just spent $XX,XXX building this product and now we are being told we have to rebuild it”
The details differ, but the theme remains the same; they have been able to build an amazing product within the budget that they had available. However, to get there, they needed to be creative with that budget.
Up until now, the product performed well, but can no longer scale to meet the growing needs of the business. There is a bit of shock when they’re told that it needs to be rebuilt for them to get to the next level.
Clearly, it’s possible to build high-performance software within a constrained budget if you know what to focus on. Focusing on the core elements that move the needle of what your market wants likely means you’ll need to make significant compromises to keep the budget in check.
Those compromises are okay if they allow you to rapidly build a product your market loves. It’s not only okay, it’s an overwhelming success.
So when the growth of the product outpaces the scale of what you’ve built, and it’s time to rebuild, we tell them:
“It’s ok. You did what you needed to do at the time to get you to where you are now. Now that you have traction and a bigger budget, you can build the robust product that the future of your business will be built on.”
We drive home that it’s ok that you’ve outgrown the first version of your product. It’s not lost money because the product's first version got you to where you’re now. In other words, it was the price of admission; it was worth it if you have customers who love your product.
A health-tech client of ours built a very scrappy PHP-based project and released it to their users. After they got paying customers that loved the product, they realized that they needed to reengineer it.
We explained that they couldn’t build the future vision of the company on the current version of the product — it would have to be rebuilt.
Of course, we kept the current version running, paid down technical debt, and made sure users were happy, but we worked with the CTO to build the architecture of the new product.
The natural inclination would have been to build on the existing tech stack, but they realized its current limitations and agreed with the need to reimagine it. They weren’t emotionally attached to the current version and were able to make rational decisions that kept them competitive in the market.
They trusted us and knew the next version of the product would have to be built on a more robust tech stack. By knowing that at the outset, it wasn’t a surprise when we proposed that as a solution. As a result, they were able to account for that in their budgeting plans.
They have since raised Series A funding and are hard at work building the future of their product.
It’s natural to feel disappointed when you have to redo something — but it’s part of the process. It’s easier to do if go in with that understanding at the beginning.
In the MVP world, your product just needs attention and traction so you can get to the next phase. In that case, it’s ok to build a product with the intention of throwing it away; as long as it gets you to where you need to be.
This is when you level up and build the next iteration because you now have the budget. You can build it to be more robust, more scalable, more efficient — but that only matters if you have traction. If you go into a situation knowing that you’re only trying to build something that’s good enough to get to the next phase, then you’re in a good spot.
This option is much better than trying to salvage it; you’ll end up accumulating way more technical debt than you can handle and hit a breaking point where the product collapses under its own weight.
Some of the biggest, most successful software companies on the planet embrace this very philosophy. Microsoft had to completely reinvent itself to be relevant for the cloud and SaaS revolution. They scrapped their old products and had to rebuild from the ground up.
It’s part of the process of staying relevant.
Throwing something away and starting from scratch is an important tool in innovation. Understanding the need for this can help plan accordingly and help manage expectations.
