The Challenge
The common SaaS dilemma - to rewrite or not to rewrite: how to scale a business when having a cranky old codebase?
The common SaaS dilemma - to rewrite or not to rewrite: how to scale a business when having a cranky old codebase?

The Problem
This story is about a very common dilemma in the tech industry - code refactoring or rewriting? How to work with legacy code? For our client, the prerequisite was: we need to bring technology up-to-date, while keeping the old codebase running (+10 years) and releasing new features.
We had to find a solution that not only allowed them to update the technology but also ensured that the old code continued to work.
The Journey
We interviewed Kris, the mind behind the challenge of merging old and new codebases, all while keeping the original app running and introducing new features in modern technologies.
Kris shared his insights into the dilemma they faced: the outdated code structure and methods made it increasingly difficult to add new features, which was a key aspect of the business. The most hindering were the lack of real-time communication between services and the absence of dynamic data exchange.
Kris recognized that continuing with the current codebase would discourage developers from joining the project, and the growth of the business required frequent releases of new features. Finding a solution that addressed all these concerns was essential for the overall success of the product. Kris explained that the end solution was a compromise - the team decided to create a new project and merge it with the old code:
"New features would be built into the new instance, using new technologies, and gated together with the old system."
This allowed for back-and-forth communication between apps. For backend technologies, it’s quite a standard thing to do; the communication on the frontend side was more of a challenge and required an additional unification of the UI. A few months later, the compromise solution proved to be effective with minimal sacrifices.
Kris expressed their satisfaction with the outcome: "Client accepted the investment of time into building the 'old app-new app' bridge. Thanks to this, we were very effective in building new features using the newest technologies, making the app future-proof. We never had to stop the development to do a full rewrite, which can cause huge losses for the business, sometimes even breaking the product altogether. There is still much refactoring that we need to do, but we do it step by step while the business can focus on growth.
Looking back now, I think there were no other alternatives. And today, because of effective communication and the use of new code, we can release new feature packs five times faster than we used to (down to 3 months, compared to 1.5 years)!"
Meet our Expert





The Conclusion
In tiered pricing (which is a standard price modeling for SaaS), one way to raise price levels is to expand services per tier; that’s why the release of feature packs as soon as possible might be essential to accommodate business growth plans. Especially in unconventional times, such as (what we’ve all experienced recently) pandemic or economic crisis - you need to navigate the pricing tiering very well. Well-designed tiers lead to direct increases in profit, research suggests, and that is more crucial than ever in unstable times.
And apart from pricing, of course, the real importance lies in providing value - and basing your price model on value first. In our client’s case, it was becoming more and more difficult to keep up with the demands of customers, and the urge to grow and build new great things couldn’t be satisfied with a technically obsolete software.


Ready to extend your team?

In this introductory call:
- I’ll listen to the problems you’re experiencing.
- Strategise how to overcome them.
- Show you some of our work.
- Tell you about our pricing.
- Answer any other questions you have!