Why You Should Avoid Rewriting Your App From Scratch

Many times, people and businesses are faced with the decision as to whether it’s worth fixing and updating something or if you’re better off starting from scratch – this can be the case for apps when certain circumstances arise. However, this is something that you can usually avoid with the right understanding of the situation at hand.

Rewriting an app is almost certainly going to be the most expensive and time-consuming when looking at all your options. Working with what you have is usually the best option and most great agencies will explore all options in this area before suggesting a rewrite as a last-ditch effort. In the following, we’re going to explain reasons to avoid rewriting your app from scratch and discuss the times it’s necessary.

The case for working with what you got

There is a common characteristic many developers possess that some might refer to as a “stereotype” where they tend to hold bias toward their work. Successful developers tend to disproportionately favor their unique style when stacked against others, viewing their way as a kind of absolute paradigm meaning everything else is inferior. 

This is a pretty big deal when you’re in the market to change development teams. But ironically, many will often dismiss an acknowledged stereotype and its potential impact which can be harmful in this situation. Understand that it’s a common mentality to hold in competitive fields like software development among others. Because of saturation in the talent pool, the market is competitive which tends to favor those who like to compete – here, good outcomes act as significant contributors to one’s self-esteem which goes hand-in-hand a hierarchical view that puts their work above that of others (a common characteristic of many extrinsic motivational models), often becoming more polarized over time. TLDR: there’s a legit reason developers are jaded.

Understand that when a developer says your existing product is garbage, it’s because of how they’re conditioned. 

Consider this: developing a product is a lot like storytelling. You have all kinds of different genres and styles between fiction and nonfiction, plus all kinds of ways to write the same story. Excluding objectively bad ways to tell a story and write code, the differences in the overall quality of an engaging tale or functioning product are measurable but still mostly subjective.

It’s also important to be aware of firms or developers that use a modern approach to justify a rewrite by using carefully-positioning, positive language. The successes observed through the phenomena of the “good-better-best” marketing strategy are because it aims to play on consumer psychology by providing a framework that inherently communicates value. Your existing product will be placed in the lowest (i.e. “good”) position, thus framing a rewrite as a definitively better option, regardless of whether it occupies the “better” or “best” spot.

Unless there is a significant, pervasive problem in an existing app, the typical outcome of a rewrite for the exact same app is usually something that’s only marginally empirically better. Mostly, it’s just different. Considering the costs and time it will take, it’s almost certainly not worth it. It’s a bit like if you were to visit the service center at a vehicle dealer to have some work done only to be told you’d be better off buying the same vehicle but one edition higher. And no, you can’t trade in the old one.

Ultimately, make sure whoever you’re working with is keeping your best interest in mind which means starting with what you have. With that said, there are select times a rewrite will produce the best results as well as incidences when it’s simply unavoidable.

The only times you should be rewriting your code from scratch

The decision to rewrite an app should come from dire circumstances when there is no other alternative. Less dramatically, there’s a handful of reasons that will require a rebuild from scratch.

One reason that a rewrite might be your option is in the event of developer hijacking. If you’ve somehow neglected to take some very simple measures to prevent incurring potential damages in the event a relationship with your development team goes south, you might be out of luck. This is why it’s vital to have access to assets like source code in its various iterations throughout the development cycle.

Without the source code, there’s nothing to build on meaning there’s no choice but to start from the beginning. Aside from hijacking, other issues with source code from it becoming irreparably damaged due to corruption to other convoluted circumstances can be cause for a rewrite. It’s like rehabbing a home that’s been through a disaster – it might just need cleaning up and some renovations but if it‘s no longer standing, you’re probably going to need to start over.

Another reason some will need to start over is that they outgrew the no code or low code solution they shouldn’t have used in the first place. These solutions often produce a kind of source code that’s either not workable with development frameworks when moved outside of its native environment or simply not accessible. This isn’t always the case but keep in mind that refactoring apps built with these kinds of solutions can sometimes require extensive refactoring to tweak everything accordingly.

Older software can sometimes be problematic depending on several factors which can sometimes lead to complete overhauls of certain components to an entire product. A good example of this would be if you have some legacy app that’s built using some prehistoric version of Fortran (or in some cases, even an updated framework.) If you have outdated code that is so far removed from the modern world, you’re probably best off redoing everything with a successor technology. Then again, it might make sense to invest in finding someone with the skillsets who can work with an outdated, even though the costs will be higher because it’s a smaller labor pool. Just be sure to carefully weight each option.

Finally, remember that “from scratch” also has a connotation that implies it’s better. Like cooking, someone can do a bad job of preparing a meal from scratch.

Blue Labs Labs works to do what’s best for our clients

Solving big problems starts with seeking out big ideas where design thinking informed by hard data and punctuated by contextual awareness plays pivot roles in our forward-thinking process. Though sometimes we do think it’s best to rebuild, most often we at how we can efficiently take your existing product to the next level. Get in touch if you’re looking for someone to improve or add to your digital product.