Once upon a time, you had some software built by either an internal or external team. At the time, it met all of your needs and delighted your customers. It was groundbreaking, innovative, and provided a much-need solution. Fast forward to now, and the software feels dated.
Your team has worked tirelessly to add in new features that were requested, but now the software doesn’t feel as polished as it was the day it was released. It feels slow, and you are losing customers to the new kid on the block who makes big claims yet doesn’t have the data to back them up.
Something has to change: the interface, the workflow, the architecture; but how do you know what needs to change? You either need to rescue what you’ve built or bulldoze it and start fresh. So which pathway do you choose?
Your situation with your software is unique. How big is your budget? How much training do your customers need? How fast do your customers expect updates? Do they expect small frequent updates or do they expect one big update? Does your software still meet your customers’ needs? All of these questions and more will factor into your decision.
Some Questions to Consider
What is your budget?
The harsh reality is that software development is expensive. You’ve experienced this first-hand with your current software. But did you know that most of the cost of software development occurs after the software is launched and as it is being maintained? Your budget will definitely inform the decision to rescue or rebuild because rebuilding is almost always more expensive, but it allows engineers to get started a little faster.
That being said, a rescue is generally cheaper but it is going to take time to get the team ramped up to a point where they are productive. That process can be kickstarted with a technical audit so the team can review the code and try to implement a change to see how brittle the code is to change.
Are you prepared to literally rebuild everything?
I cannot be blunter when I say that a rebuild means completely starting over. Everything you have already paid someone to build will be thrown away and built again. The architecture that runs the software, the API, the interface, authentication, authorization, roles, permissions, administration, dashboards, and every single feature and workflow. Every. Thing.
I cannot overstate how much rework will be done during a rebuild. The good thing is you are going to end up with a high-quality product that is free from the consequences of decisions that were made while building the previous version. However, this does come at a great cost. There will be a lot of work done before your users can even see the benefit. While it will take longer for the team to become productive in a rescue project, new features can be shipped to users sooner and quality can be improved incrementally.
Does the app still meet your customers’ needs?
This question may seem relatively simple but it is much deeper than you might think. You need to consider the current workflow and if it needs some minor tweaks or a major overhaul. If you have had a security breach in the past, that is also something that needs to be considered. Is the software you provide subject to government regulation? If so, which governments? More importantly than all of this is what your customers are telling you. You have to continue to talk with your customers even after the software has been sold to see if it continues to meet their needs. If you don’t, they will search for another solution with a provider that makes them feel heard.
If your software still meets customer needs then it is likely that a rescue is going to be the best path forward. This will allow you to make some small, “quality of life” improvements for your customers. This will not only show that you care but also improve the quality of the software you are providing. If your software does not meet customer needs, then you need to figure out what will meet their needs.
So what am I Signing Up For?
What to Expect with a Rebuild
When you choose to rebuild your software, you’re choosing to start over from scratch. There will be no technical debt that needs to be addressed. There will be no unintended side effects from new features being added to the codebase.
But it is going to be difficult to release the new version to customers until feature parity is achieved. Your customers are going to expect that every feature they currently have is going to be in the new version of your software. So it is going to take longer before customers can reap the benefits of the enhancements. If your customers require high-touch training, then you will need to prepare training manuals and sessions for them.
What to Expect with a Rescue
When you choose to rescue your software, you’re choosing to enhance what you have already built. Much time will be spent improving the code quality and writing tests for features that have been built to help ensure that new features do not break existing functionality. As engineers are adding in enhancements and tests, it is going to take time to learn the patterns and organization that has been used on the project. Oftentimes this is a much leaner approach to enhancing your software as new features can be delivered sooner. Training for this situation is slightly easier as release change notes can be communicated via email and do not require large training sessions.
Before making the final decision to rescue or rebuild, it is always best to have a technical audit performed. This is the best way for the incoming team to evaluate the software and the state of the code. An outside team will be able to identify any glaring security concerns, process concerns, quality concerns, experience concerns, etc... While it is not a silver bullet for making the incoming team immediately productive, it does help them get their feet wet so they can be more familiar with your software before kicking off your project.
As I said earlier, your situation is unique and deciding between rescue and rebuild is a difficult decision. The short answer is that it depends on your situation and having the right team to advise you is extremely important.