How to check a developer can maintain an app they didn't build

You've inherited an app. Or bought one. Or a dev team moved on and left it behind. Now you need someone who can pick up the work without reinventing it from scratch. The problem: how do you know if a new developer can actually understand and maintain code they didn't write?

This matters because an unfamiliar codebase is a liability. A developer who can't read it will guess, patch things incorrectly, break features they didn't know existed, or eventually recommend a full rewrite they're not qualified to deliver. The investment to move from one maintainer to another is real, so doing it right the first time saves money and headaches.

Request the full technical handover pack

Before you even talk to a candidate, demand that whoever owns the app now hand over a complete technical package. This should include source code (in a version control system like GitHub or GitLab, not a USB stick), documentation of how the app is structured, API keys and deployment credentials stored securely, a list of third-party services it depends on, and any known bugs or half-finished features.

If the previous developer can't or won't provide this, stop. A developer who moves on without documentation is warning you they didn't maintain standards. Any serious candidate will refuse the job under those conditions, because they know an undocumented app is a trap.

Check their experience with the app's actual tech stack

Ask the prospective developer what the app is built with: iOS, Android, React Native, Flutter, web framework, database, hosting platform. Then ask them to describe a project where they've maintained (not just built) that exact stack.

Listen for specifics. "I've worked on React Native apps" is vague. "I inherited a React Native app that was three years old, didn't have tests, and was still on version 0.65 — I created tests, upgraded it to 0.72, and onboarded a junior developer to the codebase" is concrete. They should be able to tell you what made that job difficult and how they solved it. If they can't articulate the challenges of maintaining unfamiliar code in that language or framework, they haven't done it enough.

Also ask whether they've worked with the specific services your app relies on. If it uses Firebase, Stripe, MapBox, or custom APIs, they should have maintenance experience with those, not just basic familiarity.

Ask for references who can vouch for handover competence

Request the contact details of at least two previous clients whose apps they took over mid-life. When you call them, don't ask if the developer is nice. Ask:

• How quickly did they understand the existing code well enough to make changes safely?
• Did they break anything in the first month?
• Did they spot technical debt and explain it clearly, or did they push for unnecessary rewrites?
• Would you trust them to maintain the app if you stepped back?

If a reference hesitates or says the developer was slow to get up to speed, that's a red flag. Takeover work is where a capable developer separates themselves from an average one.

Run a small, paid trial before committing

Don't sign a maintenance contract yet. Give them a specific, time-limited task: fix a known bug, implement a small feature, or add a monitoring dashboard to the app. Set a budget and a deadline. Pay them on completion.

During this trial, observe how they work. Do they read the existing code first and suggest a design that fits it, or do they rewrite sections in their preferred style? Do they ask clarifying questions about why things are structured a certain way? Do they document their changes in the code and in a summary for you? Do they set up tests for what they changed?

These behaviours predict whether they'll be a good long-term maintainer. A developer who respects the existing architecture and documents their work will save you far more than one who treats it as a chance to refactor everything.

Verify their professional standing

If they're running a formal app maintenance business or work for an agency, check they're registered with the Companies and Intellectual Property Commission (CIPC) if they claim to be a company. Ask for proof of professional indemnity insurance — it shows they've been vetted and have skin in the game if they cause damage.

For freelancers, don't rely solely on online portfolio sites. Cross-check references independently; ask if they've contributed to open-source projects you can review, or if they're active in developer communities.

Finding the right maintainer for inherited code is about verification over promises. Use Strove to search verified app maintenance specialists in your area, filter by their stated experience with your app's tech stack, and use the verification steps above before you hand over access.