It is hard to know when to invest in a technology upgrade. I’ve been in the software industry for the last 20 years and seen many times when the problems of the future become the problems of the present.

While working in solidified software products with a large customer base, periodic release cycles and stablished 3-year roadmaps, it was easy to schedule technology upgrades. The technical team agreed with the product team and management to book an specific quarter to start working in the tech upgrades while other part of the team works on still delivering features. Sometime down the road, both streams of work were merged and the production system got upgraded, then a small timespan of a few sprints was reserved to fix upcoming issues related to the technology upgrade.

Big teams can afford to work that way.

On the other hand, when a product starts from scratch, everything is more chaotic. Small teams try to quickly develop an MVP to test the market as fast as possible, therefore they spend the least amount of budget to see if the product might generate some traction, that may translate into future revenue.

At Nimble Gravity, we have worked with several Startups in this same stage over the past 5 years. I have seen, around half of the products we helped build end up getting terminated at the MVP stage because there was no market, the other half keeps growing, establishing a customer base, pivoting and adding new features.

The issue is, customer base grows, features are added, products pivot, but the technology (and maybe the architecture) gets frozen because “there are features with more priority than migrating React or upgrading to MySQL 8.0”. Revenue is king.

It is hard to convince management or stakeholders to invest on something from which they will see no immediate tangible returns.

After a few years, where the typical timespan is between 3 and 5 years, problems start to arise if there were no periodic small technology and architecture upgrades. Last year we were contracted to do one entire technology migration but only when the current system stopped working. A few examples of this are cloud VPS when their operative system entered the end of its life support cycle, database engines that are getting deprecated and out of support, code libraries that implement new features that save development time, mobile apps that get rejected from been published because they use an old SDK, and the list goes on an on.

Another good example are no / low-code based solutions that start to fall apart when they scale because of the limitations of the low-code approach.

Once the product reaches a certain maturity, it is important to reserve some budget and schedule technology, infrastructure and architecture upgrades. It is like taking your car to the mechanic, you don’t wait until it is broken, you take it regularly so they can do the maintenance service.

But, it is hard to determine the inflection point when you need to do the first tech stack upgrade and then book periodic upgrades.

We recommend doing it after the MVP stage, once the market has been tested and there is a roadmap of at least one more year of product development.

This practically means, if an MVP took one year to be built and there are more features to be built in the next stage for at least another year, the tech stack will be 2 years old once all those features are completed. It is not too early to spend budget in a non-revenue driving task, issues can start to arise at this stage. And, the technology jump (therefore the effort required to implement it) shouldn’t be as big as if you wait 4 or 5 years to do the first upgrade.

About Nimble Gravity 

At Nimble Gravity we are technology partners with several Startups and helped them to develop their MVPs, giving advice on when they should spend on upgrading their tech stacks. In addition, we also took over existing projects with old architectures and technology from new Enterprise customers to upgrade their tech stacks, which solved scaling issues that were impacting directly on their businesses’ revenue.