Taking Over an Existing App: The First 10 Days and Beyond

The first job in a takeover is not new features. It is making the product safe to change: knowing who holds the keys, being able to build and release it without the previous team, and having a baseline that shows whether a change made things better or worse.

Takeovers arrive in two forms. A planned handover happens when a vendor or internal team is moving on and there is time to transfer knowledge. A rescue happens when releases have stalled, crashes are climbing, or the previous team has already gone. The playbook below is the same for both. The difference is how much you can learn by asking and how much you have to discover by reading.

The temptation in both cases is to start fixing visible problems immediately, because the business is impatient. Resist it for two weeks. A fix shipped through a release process nobody understands, into an app with no crash baseline, is a guess. Ten working days of disciplined discovery usually pays for itself the first time it prevents a broken release.

This playbook covers those ten days, the risk register they produce, the rules for stabilising before extending, how to decide between refactoring and rewriting, how to explain findings to people who do not read code, and how to know when the product is ready to hand to its long-term owners.

Ten working days is enough to answer six questions: who controls the product, can we build it, can we release it, how does it behave today, what is it built on, and how is it put together. Run them roughly in this order, because each answer unblocks the next.

Access inventory

List every account the product depends on: source control, cloud provider, app store developer accounts, domain registrar and DNS, email sending, analytics, crash reporting, payment provider, push notification services and every third-party API. For each, record who owns it, who has admin access and where its credentials live. Pay special attention to mobile signing keys and store accounts. If an Android upload key or an Apple developer account sits with a departed contractor, recovering it can take weeks, and until then you cannot ship.

Build from clean

Take a machine or container that has never seen the project and follow the README literally. Record every missing step, undocumented environment variable and version mismatch. Time how long it takes. If the answer is "two days and three phone calls", that is a finding, and fixing the instructions is the first deliverable.

Release pipeline

Prove you can release by shipping a build with no functional changes, just a version bump, through the real path: CI, signing, store submission to an internal or test track, or deployment to staging. A no-change release is the safest way to discover that the pipeline depends on someone's laptop.

Crash and analytics baseline

Record what "normal" looks like today, with dates: crash-free users or sessions, the ten most frequent crashes, error rates on key API calls, app start time, and the handful of journey metrics the business cares about. If crash reporting or analytics are missing, adding them is a stabilisation task, and the baseline starts the day they go live.

Dependency and security audit

Run the ecosystem's own tools (the package manager's audit command, Dependabot or an OSV scanner) to list known vulnerabilities, outdated major versions and unmaintained packages. Scan the full git history for committed secrets with a tool such as gitleaks, and rotate anything it finds. Check the app stores' current target-SDK and policy deadlines, which change every year, because missing one can block updates entirely.

Architecture map

Draw one diagram: apps, services, databases, queues and external providers, with arrows for data flow. Mark where money, identity and personal data move. Then note where tests exist and where they do not. The map does not need to be beautiful. It needs to let the next engineer find where a change belongs.

A risk register is a single table of everything that could hurt the product, scored so the team works on the most dangerous items first. Score likelihood and impact from 1 to 3 each, multiply them, and sort by the result.

The scores in this table are illustrative; yours will depend on the product. Three habits keep the register useful:

• Every row has an owner and a next action, not just a description.
• Rescore it weekly. A risk that has been worked should drop. A row whose score never moves is being ignored.
• Control risks usually outrank code risks. Ugly code slows you down. A lost signing key or an account you cannot reach stops you completely, so those rows go first even when the code is worse.

Stabilising means making releases boring before making the product bigger. Until a change can be shipped, measured and rolled back safely, every new feature adds risk to a system you do not yet understand.

Six rules for the stabilisation phase:

1. Freeze non-essential features for a stated period, with the business's agreement and an end date. The right length depends on what the first ten days found; agree it up front rather than leaving it open.
2. Fix the release path first. Nothing else matters if you cannot ship the fix.
3. Test before you touch. Before changing a critical journey, write characterisation tests that pin down what it does today, including the odd behaviour users may depend on.
4. One kind of change per release. Do not mix a dependency upgrade, a refactor and a bug fix in one build. When something breaks, you want to know which change did it.
5. Ship behind flags where you can. Remote flags let you switch off a change on mobile without waiting for a new store review.
6. Measure every release against the baseline. If crash-free sessions drop or a journey slows down, stop and look before the next release.

Stabilisation is finished when these conditions hold, not when the calendar says so:

• Anyone on the team can release from CI without help.
• Critical journeys, such as sign-up, payment and the core action, have automated tests that run on every change.
• Crash and error rates have held steady or improved across several releases.
• Every high-scoring row in the risk register has been closed or has a dated plan.

Then you extend, and extension goes faster because the ground is firm.

Most inherited products should be refactored in place, not rewritten. Rewrite only when the platform itself is the constraint, the behaviour is well understood, and you can afford to run old and new side by side while you switch.

Be honest about what a rewrite costs. It is not "the time to build it again". It is roughly:

rewrite cost ≈ rebuilding the known behaviour + discovering the undocumented behaviour + maintaining the old system in parallel + migrating users and data + the regressions you will ship anyway

The second term is the one teams underestimate. A product that has been in use for a few years encodes decisions nobody wrote down: a rounding rule, a special case for one partner, a workaround for an old OS version. The old code is the only specification, and a rewrite has to rediscover each rule, often by breaking it in production.

The usual middle path is incremental replacement, often called the strangler fig pattern: put a boundary around one area, build the new version behind it, switch traffic or screens over, and retire the old code. Each step ships on its own and can be reversed. Cross-platform frameworks often support this directly; Flutter's add-to-app, for example, lets new screens live inside an existing native app.

Our own approach starts the same way every time: a focused review of module boundaries, performance on the important journeys and the release process, then fixes ordered by risk. A rewrite is a valid outcome of that review, but it should be a conclusion, not a starting assumption.

Translate every finding into what it could do to customers, revenue or the team's ability to ship, and give options with their consequences. A list of technical complaints, however accurate, does not help anyone decide.

A findings summary that works on one page:

``` CODEBASE REVIEW: SUMMARY (illustrative)

Overall: Amber. The product works for users today, but we cannot yet release it safely without outside help.

Top risks 1. RED We cannot publish iOS updates. The Apple developer account belongs to the previous agency. If unresolved: no fixes or features reach iPhone users. Action: transfer request sent; recovery path started. 2. AMBER Checkout has no automated tests. If unresolved: a routine change could break payments without anyone noticing until customers complain. Action: tests for checkout before any change to it. 3. AMBER A core library is no longer maintained. If unresolved: a future OS update may break login. Action: isolate it now; replace within the quarter.

Options for the next month A. Stabilise only (recommended): features paused, releases safe by the end of the month. B. Stabilise and ship one small feature: about a week later, and slightly more risk to the release.

Decision needed: A or B, by Friday. ```

A few principles make this land:

• Lead with the overall picture in one sentence before any detail.
• Use "if unresolved" statements. "No fixes reach iPhone users" is understood instantly, while "certificate ownership issue" is not.
• Offer options, not ultimatums. Leaders decide better when they can see the trade-off.
• Do not blame the previous team. Most inherited problems come from deadlines and changing priorities, not incompetence. Blame also makes the outgoing team less helpful during handover, and you still need them.
• Separate facts from estimates. "The account is held externally" is a fact. "Recovery may take weeks" is an estimate, so label it as one.

A product is ready to hand over when someone who did not build it can build, release, monitor and change it without calling the people who did. Use this checklist at the end of a takeover, and again before any team steps back.

Control

• Every account, key and secret is owned by the client's organisation and listed in one access register.
• Signing keys and production credentials are in a managed vault, with at least two named people able to reach them.

Build and release

• A new engineer can build every component from a clean machine, following written instructions, within a day.
• Releases run from CI, and at least one release has been done by someone other than the author of the pipeline.
• Staged rollout, rollback or remote-flag procedures are written down and have been tried once.

Operation

• Crash reporting, error monitoring and key journey dashboards are live, and someone receives the alerts.
• A runbook covers the five most likely incidents, such as a bad release, a provider outage or an expiring certificate.
• A support path exists: who triages user reports and how they reach engineering.

Knowledge

• One architecture diagram and a short written overview are current.
• Decision records explain the important choices and the options that were rejected.
• A known-issues list and the current risk register are handed over openly, not discovered later.

If any line is unchecked, it should appear on the handover plan with an owner and a date.

This playbook is how we approach the work we describe as strengthening the foundations: untangling an existing system, making release decisions clearer, and leaving the client's team ready to own it. It follows the same four beats as every engagement we run, with the first milestone shaped around the ten days above.

1. Fit and risk. We ask what is failing, what must not break and who holds the accounts. If the honest answer is that the product needs a different kind of team, we say so.
2. A bounded first milestone. Usually the ten-day review itself, ending in a risk register, a stabilisation plan and a stakeholder summary you can act on whether or not we continue.
3. Visible weekly work. Repository access, release notes, a risk register that is rescored in the open, and written decisions.
4. Handover. The checklist above, worked through with your engineers, paired on the hard parts.

If you are about to inherit a product, or one has stopped shipping, start with our services overview or describe the situation: the stack, what is failing, and who currently holds the store and cloud accounts. If you are hiring a team for the first time, our guide to briefing a product studio covers what to send.

How long does it take to audit an existing codebase?

A focused review of a typical product fits in about ten working days: access, a clean build, a test release, a crash baseline, a dependency and security audit, and an architecture map. Large systems with many services take longer, but the first findings should still arrive within two weeks.

Should we rewrite our app or refactor it?

Usually refactor. A rewrite makes sense when the framework or runtime is no longer supported, the behaviour is well documented, and you can run old and new systems in parallel. Otherwise, replace the system piece by piece behind clear boundaries so each step can ship and be reversed.

What do we need from the previous developers during a handover?

Transfer of every account and signing key, working build and release instructions, credentials for each environment, and a known-issues list. A few recorded walkthrough sessions on the architecture and release process save weeks of discovery. Ask in writing, and start account recovery in parallel if the response is slow.

What should we do if the previous agency will not hand over our app store account?

Request the transfer in writing, citing your agreement, and start the app store's own account recovery or transfer process at the same time. Keep a record of every request. Going forward, create store, cloud and signing accounts in your own organisation and grant vendors access, never the reverse.

What is a risk register in a software project?

A single table of everything that could harm the product, each item scored by likelihood and impact, with an owner and a next action. Sorting by score tells the team what to work on first. It should be rescored weekly so that progress, or neglect, is visible.