Rebuilding a Mobile App from Scratch: Lessons in Project Management

Rewrite a mobile app from scratch, Lessons I’ve learned in managing apps

How tricky and what the reality of the learning curve of a full mobile app rewrite is.

Rewriting mobile app: “This is brilliant”, I remember thinking. A new repository, zero tech debt, a completely clean slate architecture and a brand new canvas upon which to build. But this in truth is the death of any project management task.

I once knew of a startup with limited funding that had to pay eighty thousand dollars and four weeks in development time in order to perform a complete rewrite of its mobile app because its old app code was ‘too messy and too difficult to maintain.’ In prioritizing how ‘good the app looks’ over how ‘good the app actually works’ the new front end probably arrives in a semi-broken state and the users are already used to a half missing feature-set. The goals of this mobile app rewrite: an incredibly powerful, and therefore uncontrollable car that ultimately kills retention.

The mistake: Feature parity

It has been common over recent years for freezing feature maps and handing single groups of engineers ownership of an entirely new application whilst they focus 100% of their energy on the rewrite itself to appear an extremely efficient way forward. The problem: no-one realizes that as their app architecture is being rewritten and refined, other developers and teams are successfully adding features to their own product offerings and advancing their own product strategy.

Sarah, a technical lead whose app we have been assisting this quarter had managed to execute a full native rewrite of her app and had effectively ironed out large chunks of state-management. Once the app was submitted, the market had moved on and the data models were already outdated.

The amount of knowledge that has to be built into even the most hopelessly messy application is astounding — the product of years of hacking, bespoke webhook requests, and highly custom error handling for obsolete mobile operating systems. As is evident with every complete app rewrite, each part of what you thought you knew about architecture has to be relearned.

The alternative is iteration

Treat the codebase that you have as a tool to refine, not an enemy to destroy; Continue to build on your live, running, revenue generating app, and then optimize and partition from there.

Metrics: - The Full Rewrite (BAD) - The Extraction: The Solution - Retain Revenue - Zero new features; app kept running and secure

Data corruption due to schema differences, errors due to matching incompatibilities and the necessity for massive, sequential, robust and secure data synchronization mechanisms, requires extensive testing; the testing of the new application will need to be intensive, end-to-end and automated.

The Strangler Pattern

If a complete rewrite cannot be avoided (i.e. If you are migrating hybrid app code to a full native one or moving to Flutter), the Strangler Pattern will be helpful; you’ll pull out the most critical function that needs re-writing (perhaps a slow cache or repeated failures for third-party integrations) and run it as an independent service. You then route all traffic through that service with a proxy and see how performance increases over the course of a few weeks while closely monitoring that particular process in a staging environment.

Keep your pipeline clean

Assuming a rewrite has to take place, you must insist on high standards of quality; developers are not allowed to write custom state management routines unless they have extensively tested them, and no new libraries can be incorporated without a lot of research. Write rules into the code review stage and ensure all commits are tested and linted before being merged into master. Discard developers who are unable to accurately trace data serialization or to reliably guess the state of the app if the connection is interrupted while asynchronous events occur.

Accept that you need to favor structure over speed and that learning to iteratively rewrite an inefficient but revenue-generating application is the true art; a perfect blank canvas can be fun for the developer, but unfortunately nobody else cares. Did your app have a problem with technical debt or was it an issue for you in dealing with someone else's work?