Taking over a mobile app already in production: the Par2 case

This case study is different from the others published here, and it is worth saying straight away: we did not create this app. It was built by another team, published on the App Store and Google Play, and it already had its users when it was handed to us.

The app is Par2, a dating app for the golf community: profile discovery, matching, messaging, forums, events, subscriptions. A complete product, with real people behind it.

What follows is the account of a handover. It is a far more common situation than people think, and rarely told.

Taking over is not starting again

The first instinct, when you inherit an app you did not write, is to redo the lot. It is also the most expensive.

An app in production is not just code: it is installed users, established habits, behaviours validated by use, and a quantity of small decisions nobody documented but which exist for a reason. A rewrite takes months to recover all of that, and during those months users get neither new features nor fixes.

So we kept the base and worked inside it, in a specific order. That order is the real subject of this article.

First: data access

An app of this kind keeps its data (profiles, photos, messages) in a hosted database. Who may read what, who may write what: that is described in a set of rules, and it is those rules that protect users.

It was the first job we handled, ahead of any new feature. Every rule was gone over and aligned with what the app actually does, then covered by automated tests so that a later change cannot loosen it without us seeing.

The order of priorities matters, and it is counter-intuitive from the client’s side, who is generally expecting features: it is the only job whose cost rises with time. Every feature added before it is one more feature to revisit afterwards.

Second: a staging environment

The second invisible job, and the second condition for moving forward without breaking anything: being able to try something without doing it on real accounts.

So an isolated staging environment was built: its own data, its own database, and a test dataset that can be reset as often as needed. On top of that sit technical guardrails preventing a test session from talking to production, even by mistake.

That is three or four days of work producing nothing visible to users, and it changes everything: from then on, every fix can be checked before it ships, instead of being a gamble.

Third: making it solid, in small pieces

Once you can test, you can repair. This phase covered the journeys that matter most in a matching app: sign-up, which is the very first thing a new user sees, the matching screens, notifications in every language offered, and robustness in the face of incomplete data, which is the leading cause of a frozen screen in any app.

Nothing spectacular, and that is the point: these are ordinary fixes, shipped one at a time, each of them checkable in staging before it reaches users.

What was added next

A handover is only worth doing if it leads somewhere new. Once the foundations were sound, the product moved forward.

A golf and events section. The app now has a directory of clubs with detailed entries, favourites, persistent filters and sorting by distance, plus a calendar of competitions and events sorted by proximity. It is the same directory as the public site’s, filled in by the club managers themselves.

Work on languages. The app went from two languages to six, Arabic included, which meant handling right-to-left reading: the whole interface flips, and that switch had to hold from one launch to the next. The system permissions the phone asks for (location, photos, notifications) were translated too, which almost nobody does.

Less spectacular but useful things: retention at account deletion (offering a pause rather than a goodbye, and collecting the reason), a page for suggesting a feature, an analysis of the profile discovery journey on real data, and releases shipped regularly rather than in fits and starts.

What to take from this if you inherit an app

If an app lands in your hands without its original team, four points from this case are worth keeping:

1. Do not rewrite everything. An app in production has users, behaviours validated by use, and a value a rewrite takes months to recover.
2. Start with data access, before any new feature. It is the only job whose cost rises with time.
3. Give yourself a staging environment. Without one, every fix is a gamble and every release is a fright.
4. Have a written assessment made. A few days of audit tell you whether the base is sound, repairable or lost. It is the most profitable spend of the whole operation, including when the conclusion is “start again”.

And for your project

Our published offer covers websites, with prices on display and a free quote within 24 hours: it is all on the website design page.

An existing mobile app, its handover or its maintenance, is something we look at case by case. If that is your situation, write to us describing what exists: we will tell you honestly what we think, including if the answer is that it is not for us.

Frequently asked questions

Do you have to rewrite everything when you take over an existing app?

Almost never. A full rewrite costs months, loses behaviours nobody had documented along the way, and leaves users without new features or fixes in the meantime. The right method is to secure data access first, give yourself a way to test second, then move forward in small shippable pieces.

Where do you start when you inherit an unfamiliar app?

With data access, before any new feature. It is the only job whose cost rises with time: every feature added before it is one more feature to revisit afterwards. Next comes a separate test environment, without which every check would happen on real accounts.

Can you test an app without touching real data?

Yes, by setting up a staging environment with its own data, isolated from production, and a test dataset you can reset at will. It is a few days of investment that pays for itself with the first fix you dare ship with a clear head.

What does taking over an app cost compared with building a new one?

It depends entirely on the state of the code, and it is assessed before committing: a few days of audit tell you whether the base is sound, repairable or lost. In most cases a handover costs considerably less than a fresh build, because the product already exists, it has users, and its features have been validated by use.

Do you build mobile apps?

Our published offer covers websites, with prices on display. A mobile app, its handover or its maintenance, is handled case by case after a conversation about what exists. Tell us your situation and we will say honestly whether it is for us or not.