At a certain point in any software product’s lifecycle, the question has to be asked: Is it time for a full rebuild of our software? It may not be in a month or a year or 5 years… but eventually, the question has to be asked.
No software product exists in its original form indefinitely. At some point in time, a major code refactor and/or full rebuild occurred (even if the software carries the same name). It’s a daunting prospect, but one that every company has to face at some point. So, we put together a list of questions to help you evaluate whether your product’s time has come…
Now, a yes to any one of these doesn’t mean you shouldn’t necessarily kick off a full rebuild right this second. Rather, it’s a framework for thinking about your software’s lifecycle. We want you asking the right questions and understanding what the implications might be if you’re answering “yes” to too many of these.
A good rule of thumb: 20% of budget time/resources should go toward maintaining a product and 80% should go to adding value to the product. If you’re not there or if your time/resource usage is inverted from that, it may be time to rebuild.
The bottom line here is: if you’re not coding true enhancements, but rather constantly coding workarounds, it might be time for a rethink.
This isn’t necessarily a telltale sign a rebuild is imminent, but it can often point to a larger problem brewing for your software.
Are you having to read new folks in for every update or maintenance issue? Beyond that, is developer ramp up time high? Does it take more than a week or 2 for experienced or mid-level developers to get up-to-speed enough on your systems or product to implement their first commit on a small feature?
These could be warning signs that a rebuild might be the way to go.
For up-to-date software, deployment should be automated and (relatively) painless. Obviously it doesn’t always go down that way, but that’s the idea.
If every time you want to add a feature or enhancement to the live environment you’re doing it by hand, and it takes a long time — this is a sign you’re probably improving something that’s better off rebuilt.
This is a pretty simple one, and usually means the rebuild needs to happen pronto. Are there new features or integrations you’d like to add to your software but simply can’t because that feature or integration isn’t supported by your existing codebase or language?
This usually means the prevailing technology has passed you by. If you’re unable to add valuable functions or integrations because your tech is too antiquated to be supported, a rebuild is almost certainly in order.
If this sounds familiar, you may need to rethink some things: when you fix one bug or problem, make one change, it creates another issue elsewhere. Is your dev team playing whack-a-mole with issues? Every time they resolve something, another one crops.
This means, at a base level, your software is unstable. And if that’s the case, you guessed it, a rebuild might be the way to go.
This usually happens when your solution is built on an outdated coding language or platform. It goes something like this:
This also will often look like this: developers don’t want to work on the product. Devs want to stay up with the trends and stop improving on legacy languages.
Like I said in the intro, it’s not a death sentence if you said yes to any specific one of these questions. But if you’re seeing a theme developing across them, it may be time to consider asking some questions.
Full rebuilds can be a beast. It takes time, resources, money… We get it. We don’t recommend it lightly, and certainly not before we get a full picture of what’s under the hood.
That’s why our Innovation Lab is such an important step whenever we talk with a company that’s considering a rebuild. It’s soooo important to gain a deep understanding of the client’s pain points, their customers’ needs/wants, the resource allocation required, investment that’ll be needed, etc., before you do anything as drastic as a full rebuild.
If you did answer yes to too many of these questions, we’d love to chat with you. No hard sell, no pressure — just open and honest communication. A full rebuild might not be the right move, ultimately! But that’s why we go slow in the discovery phase, so that we can go fast in the development stage. Whether it’s a small refactor or a full-scale rebuild, we understand the root of the problem before suggesting the best way to counter it.