A full rebuild — how do you know it’s time?

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.

Are you spending more time trying to keep your system running and maintained than you are building new, valuable features or improving the product?

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.

Is everyone from the original project team gone? Or are you no longer contracted with your original vendor?

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.

Does your application have an overly long deployment cycle?

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.

Are you unable to add new features or integrations?

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.

Do you have a baseline fear of altering live code for fear of something breaking?

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.

Is it slow & expensive to update or maintain your code?

This usually happens when your solution is built on an outdated coding language or platform. It goes something like this:

• Finding coders still fluent in that language is difficult
• If you do find them, they’re expensive. Their skillset is now considered “niche”
• Because it’s old code, and you have limited resources who can work on it, it’ll take a long time to implement even if you do invest the time and money into it

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.

For example, if they were a PHP developer, they probably migrated to a JavaScript framework and mostly work in Angular or React now… they’re unlikely to want to go back to a PHP project because they haven’t stayed sharp over the last few years, and fewer products require it going forward.

The bottom line

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.