Why You Should Avoid Rebuilding Your Codebase

When startups rebuild their tech, they often make the same mistakes. Here's why you should avoid refactoring your codebase and how to succeed without it.

‘We’ll probably have to rebuild this one day.’

What starts as an innocent comment can quickly turn into something that comes up at every technical meeting. The backlog is filled with bugs, and less of the sprint is focused on generating value for customers. Iteration cycles take forever, and new ideas are quickly shrugged off as impossible to implement.

Great effort is required for relatively low return and as progress slows, competitors start to rush past you. It’s demoralizing for the technical and non-technical teams alike. Eventually, it’s pure frustration for everyone. 

Learn new skills every week ->

How did we get here?

If rebuilding is the topic on everyone’s list, it’s worth figuring out how you arrived here, before figuring out how to proceed. I’ve seen — and been in — this situation multiple times, so I can hazard a few guesses.

1) You took so many technical shortcuts.

At the time, it made business sense: you needed to close the deal, implement the feature, and close the partnership. However, shortcuts can have a nasty habit of coming back to bite you. If you don’t spend enough time refactoring code, the interest on your technical debt will go through the roof.

Failure to invest in refactoring could be a symptom of inexperienced technical leadership, but it’s often down to technical leaders lacking empowerment . . . or maybe even being ignored altogether.

2) You aren’t involving developers in your design process.

The design process needs to marry customer needs with technical feasibility. If you’re only involving programmers once the design has been finalized, you’re unlikely to make best use of your existing technology.

This leads you to create bespoke solutions, rather than leveraging existing libraries, conventions, or off-the-shelf solutions. It’s easy to underestimate how expensive custom code is to maintain.

3) You adopted a waterfall development process.

Waterfall development is characterized by long iteration cycles in which scope is fixed. This can be useful for projects with a very high degree of technical and business certainty, but startups are about as uncertain as they come. As a result, a waterfall approach routinely leads to over-building and feature bloat.

This is in stark contrast to agile methodologies, which emphasize the importance of iteration and building feedback loops that allow you to accommodate your customers’ changing needs.

Learn new skills every week ->

The answer to your prayers

A ‘big-bang rebuild’ is appealing for a variety of reasons. It represents a blank canvas onto which you can project your hopes and dreams,. and best of all, there’s no more dealing with complicated code written by someone else.

However, by pursuing a big bang rebuild, you might be perpetuating most of the mistakes that led you here in the first place. Locking in scope and expecting nothing to change for six to twelve months is inevitably going to fail. It’s the antithesis of adapting to changing customer needs.

What’s more, big scopes are destined to be underestimated. Complexity increases exponentially with scope, so working on a large project that’s four times bigger is sixteen times less certain. Whatever your most conservative release dates might be, add six to twelve months (at least).

The initial excitement of any new project will soon wear off, and a few weeks in, the tech team will start to become demotivated. They’ll have underestimated many of the complicated challenges that are likely to come up. And as they won’t be shipping to customers regularly, most of their work will be completely invisible — not only to customers, but to the team at large.

If the product doesn’t improve over an extended period of time, non-technical employees in marketing and sales will feel trapped, and they’ll jump ship faster than rodents on the Titanic. Once the deadline is missed, the whole company’s morale will fall off a cliff.

Slicing the pie

The alternative to a big bang rebuild is far less appealing: think slow migration, not big bang. Rather than approaching all the different problems at once, look to slice off those problems one-by-one.

Here are a few tips to help you undertake a slow migration process.

1) Uncover the emotional reality.

If ‘rebuild’ keeps coming up it’s a signal that your team is frustrated. Try this exercise with your team: ask them to imagine that the rebuild is finished and the tech works perfectly. Then, pose these questions:

• How will your life be different?
• What makes you most relieved?
• What most excites you?

By asking these emotive questions, try to get the specifics of what will really make a difference to your team. This will help you focus your efforts on the real issues.

2) Brush up on your agile concepts.

A rebuild is often a great time to invest in agile training for the whole team. And in my experience, agile training has a massive return on investment, giving team members a common framework to tackle problems just like this.

3) Simplify every chance you get.

By the time you reach the need to rebuild, you’ve probably accumulated features that very few customers actually use. There’s no rule that says you must replace every single feature. Instead, look for opportunities to kill features and simplify your product.

Learn new skills every week ->

4) Focus on customer value.

Once you’ve broken your tech down into manageable chunks, prioritize the rebuild on a one-by-one basis, focusing on the smallest chunks that add the biggest customer value.

5) Build in time to refactor.

It’s tempting to take an incremental approach and keep working on the next thing. Instead, ensure that you make time to improve your existing code. For example, you could assign 25% of sprint resources entirely to proactive refactors.

A test of leadership

A technical crisis is a true test of leadership for every founder. Migrating is never going to be the most popular option, nor the most exciting. But it’s likely to get you a better result than a rebuild.

Just as with every leadership challenge, it’s going to require a lot of empathy — and a lot of listening to your team. Communication is key and it takes discipline to keep the team aligned. And lastly, you need patience — there is no quick solution if you’re in this situation. Things are going to take longer than you want . . . which is why it’s time to be a little more agile.

Continue reading about brand rebuilding: 

• Running out of tech resources? Learn why outsourcing tech is a better option for startups.
• Coming up with a new product?  Run through my dos and don’ts for product ideas.  
• Running a company with little technical skills? Here's when to hire a technical co-founder for your startup.  

Originally published Jul 23, 2019, last updated Jul 27, 2023