The Pros and Cons of Rewriting an App From Scratch | App Owners Guide

Does your product have legacy code and does it suffer from all of the disadvantages that come with it? Is the average time to market of seemingly simple features is ever-soaring? Is it constantly getting harder and more expensive to find developers willing to work in the obsolete technological stack your application is using? Is your product bombarded with bugs and/or performance issues?

When these and similar questions begin to haunt Product Owners, they may face a dilemma determining whether or not to completely rewrite the application from scratch. So, when is it worth rewriting a legacy app from scratch? In this article, we will look at some points that can help you make up your mind and eventually make the right decision. Before we dive into the pros and cons of rewriting an app from scratch, let’s explain briefly what app rewriting means.

What is app rewriting?

First off, let’s define what project rewriting really means. This definition is necessary to make sure that we’re on the same page. There are already numerous articles that discuss software project rewriting. As a result, there are multiple definitions of what one considers as a rewrite.

There’s the complete rewrite (aka rewrite from scratch), and then there are functioning definitions of a partial application rewrite, also called revamping, reworking, adapting or porting. As you can see, the notion of a software product rewrite can get confusing pretty quickly.

Here, we will focus on rewriting an application from scratch. This approach comes with several advantages and also some disadvantages, as opposed to project refactoring.

For now, just keep in mind that I’m referring to a complete rewrite of an application, which can still sometimes allow for the reuse of certain bits of code. For example, the implementations of algorithms or various (properly isolated) business use cases can sometimes be easily reused, as long as the business requirements haven’t changed.

On the contrary, project refactoring focuses heavily on reusing the old code and only rewriting certain parts from the ground up. The line between the two is thin, depending on the definition you assume.

For more a more precise explanation of the refactoring process and when it’s better to choose it over rewriting, please refer to our Refactoring vs. Rewriting a Mobile App – Comparison for App Owners article.

Pros of rewriting an app from scratch

Faster iteration

The app rewrite usually also includes a redesign of the app architecture. The new architecture should ensure that the code will be easy to change and improve in the future. This will result in a faster iteration moving forward, as well as a shorter feedback loop.

Limitless & faster development

Developers won’t in any way be limited by the existing code – making it easier to use more up-to-date technologies. This will help you make sure your application is developed using state-of-the-art technologies. It’s not an empty, flashy buzzword. New technologies are the most popular ones. Software engineers love to be up to date with them. This means you will have more developers to choose from on the market, should you decide to expand your development team.

Every Product Owner of a legacy app knows just how difficult finding developers for an old language or framework can get. Apart from that, the more popular the technology, the better and larger the community around it. This means there’s more knowledge on how to deal with the bugs and problems developers stumble upon. This, in turn, means a faster app development process.

Read also: How to Speed Up Native Mobile App Development?

Avoid past mistakes

Provided that you have assembled a team of developers experienced in conducting large rewrites, the new development team will probably be able to refrain from making the same mistakes the previous developers did. For that to happen, you also need to be in full control of the business domain knowledge.

Read also: 6 Common Mistakes to Avoid when Developing a Mobile App

Refreshing the app design

App rewriting allows you to rethink the overall app design and modules, as well as its optimization. You have a great opportunity to revamp your User Journey Map and make sure that every step along the way is self-explanatory to the end-user. Remember that a well designed UX is one that needs no explanation.

Rethinking app features

You have a chance to verify whether your product solves users’ problems in the most effective way and decide what features it should really have. A rewrite is a perfect opportunity to do this, as you will probably revisit the User Journey Map or a similar document anyway.

Risks of rewriting an app from scratch

Benefits your competitors

Deciding on a complete rewrite without maintaining the old app at the same time is like giving your competitors a free year or two’s head start (for example, on building new features). That’s a lot of time from a business perspective. Entire companies have gone out of business due to such poor strategic planning.

Time-consuming

Time is a crucial resource that will be consumed during a rewrite. Some of it will be wasted unless it serves a purpose and solves critical problems. Along the rewriting process, some initially hidden business requirements will probably appear, and additional delays may happen.

Rewrites working features, too

A rewrite discards the parts of the application that worked as required. A rewrite demands that developers implement all of the features again. This is inevitable when the application gets rewritten in another language or framework, and it’s a strong point against rewriting when the product will continue to use the same technological stack.

So, when we are talking about rewriting applications using exactly the same technologies, even a piece of code that is perfectly fine will often have to be rewritten. Why? Because it likely does not fit into the new architecture. If we would leave such an old piece of code, we would immediately have to use some adapters so that the new architecture could use this old part. That is a red flag because the legacy code shouldn’t control the new architecture.

There are some exceptions – you can copy some mathematical algorithms, for example – but these are rare cases.

Wastes previous bug fixing

Previous efforts directed toward fixing bugs go to waste. The previous version of the project might have had a lot of expertise and development time devoted to fixing bugs. The developers might have been forced to work around issues deriving from the used technologies and frameworks alone. Some of the bugs in the app will always be connected to used libraries and architecture and wouldn’t show up otherwise. Undertaking a complete rewrite is as if all this effort was for naught.

Raises stakeholders expectations

You have to meet your organization’s expectations. Stakeholders from across the company will surely expect a return on investment when an application is to be rewritten. For example, it could be better UX/UI design, improvement in development speed, improved overall product performance, better app rating from the users, better user retention, or more new users in general. Product Owners have to manage these expectations. You’ll be the one to convince the stakeholders that the cake is worth the candle.

Let’s sum up the pros and cons of rewriting an app from scratch:

When would rewriting a legacy app be a mistake?

When a new team gets to see an inherited project code, it might often seem righteous to convince the client and start afresh. It so happens that it’s just not always the best possible option for the App Owner.

Moreover, rewriting an app with the same development team that produced the original version is seldom a good idea. Suppose the developers piled up too much technical debt due to various reasons (pressing deadlines, low skilled developers). If this were the sole reason, the company most definitely shouldn’t undertake a complete rewrite.

If the developers demand a rewrite decision solely in the hope of escaping the mess they are accountable for (among others), it suggests you lack reliable processes. Every App Owner should know that rewarding the team with a blank slate without taking the time to discover why these problems popped up in the first place, and possibly revamping the organizational processes, will likely lead to the same situation – creeping technical debt.

Even if you’re certain of having a great team of developers, a lot depends on the industry cycle of activity. You shouldn’t aim for a rewrite if there’s a lot of pressure from your competitors. Deciding for a complete rewrite means that releasing new features will come to a standstill for a long time.

Unless, of course, you have the time and resources to undertake a rewrite and maintain the current product version in parallel. If your business focuses on a specific niche in the market, your time to the market metric will be of utmost importance. In this case, you should harness all of your resources to make sure you will be able to secure the desired part of the market cake.

Do a background check on a potential development team for your app rewriting

As I’ve already mentioned, the crucial thing when it comes to rewriting an app from scratch is making sure that the designated team is able to live up to the expectations. Ideally, you’d like to get some insight into who the developers are, what their backgrounds are and a sense of their overall experience. You can either look for such details on professional social media, like LinkedIn, or developers’ private Github repositories.

If you decide to team up with a software development company, this becomes even easier. A company valuing transparency towards its clients will be willing to share some of these details with you. For example, you can get details about the projects in which the specific developers were involved or some metrics about client satisfaction.

Keep in mind that you might not be able to get the exact product names, as many of the projects are developed under strict non-disclosure agreements. Here, you can read an in-depth article about how to check a potential partner for your app development.

Projects that are to be rewritten come in many shapes and sizes. If you have a large, complex product, you’ll be far better off having hired a team of well-suited software engineers.

In the long run, it’s simply worth paying extra for experienced developers who have previously worked on projects with complex domains and large codebases. Such seasoned developers can lead you through the process of collecting business requirements themselves, asking you smart questions and therefore being able to quickly grasp the ins and outs of your business domain.

Make sure the team knows about your future plans and additional features

It’s agreed that this is not always feasible. Or at least not completely. That said, I’m not trying to convince anybody to go back to using the Waterfall model (which was a complete mistake for IT projects).

The thing is, if you…

• know your domain from the business standpoint,
• have even a vague product roadmap,
• are able to grasp and lay an almost complete set of features out,
• and maybe have some sort of a user journey map…

it will make things much easier for the developers and people responsible for choosing the right architectural patterns. The more you know about the planned product functionality upfront, the less convoluted the code will be in the future. Again, we’re not talking about the waterfall process but rather about the result of a well-conducted Product Design Workshop / Product Discovery.

More often than not, a software development agency will also offer a Product Design Workshop service. This is an ideal opportunity to convey your vision of the application and your requirements to the development team. A few days of these workshops will provide the team with enough knowledge for the months to come. Along with the software engineers, you can then try to trim the features to those few that are crucial for launching the application (Minimum Viable Product).

At the same time, the broader vision presented to the developers will already make them capable of planning the architecture. They will be able to structure it in a way that makes adding the new features virtually painless, drastically limiting the influence of legacy code in the future. What is legacy code, and why should it be feared? You can read more in our article focusing on the comparison of refactoring and rewriting the application.

The pros and cons of rewriting an app from scratch – conclusion

As tempting as it may seem to developers and Product Owners alike, rewriting an app from scratch is not always the best option from a business perspective. As a Product Owner, you have to take numerous factors into consideration to make sure that this is what your organization needs to thrive. Get a Free Ebook – Product Owner Guide.

Should you, based on this guide, decide that rewriting is the way to go, keep in mind that there are still a lot of caveats to consider ahead. First and foremost, you have to be sure that you are relying on a team of seasoned developers for whom this isn’t their first rodeo.

The chances of succeeding in a complex application rewrite soar in direct proportion to the experience of developers, and just how good of a team they create. Apart from that, make sure to do everything to convey your vision of the app to them. The better the team understands the business domain, the better and more efficient their work will be in the long run.

Related posts