The First 48 Hours — What to Secure
Before you look for a replacement developer, before you evaluate the code, before you do anything else — you need to secure the assets that can be lost permanently. This is triage, not strategy. Strategy comes later. Right now, the priority is making sure nothing disappears while you figure out your next move.
Repository access. The code for your app lives somewhere — usually a platform like GitHub or GitLab. The question is whether it lives under your account or the developer's. If it's under yours, you're fine. If it's under theirs, you need access immediately. Fork it, transfer it, download it — whatever you can do to get a copy under your control before the developer's account lapses, goes private, or gets deleted. If you can't access the repository at all, this is your single highest priority. Without the code, everything else is academic.
App store credentials. Your Apple Developer account and Google Play Console — are these under your email address or the developer's? If the developer set them up using their own email, you have a problem that gets worse with time. Apple Developer accounts require annual renewal. If the developer's account lapses, your app gets pulled from the store. Google Play Console accounts don't expire the same way, but if you can't log in, you can't push updates, respond to policy violations, or do anything at all. Transferring app store accounts is possible but bureaucratic and slow. Start now.
Signing keys. This is the one that catches people off guard, because it's the most technical and the most consequential. Every Android app is signed with a cryptographic key — a keystore file. Every iOS app uses certificates and provisioning profiles. Without these, you cannot publish updates to your existing app listings. Not "it's difficult." Not "there's a workaround." You cannot. If you've read our article on app rewrites, you already know: without the keystore, you cannot update your app. Period. Find out if you have these files. Find out if the developer stored them somewhere you can reach. This is not something that can be reconstructed later.
Backend and server access. If your app has a backend — a server, a database, an API — where is it hosted? Who pays for the hosting? Do you have the login credentials? Do you have SSH access, database passwords, environment configuration files? If the developer was paying for the hosting out of their own account and they stop paying, your backend goes offline. Your app stops working. Not in a "degraded experience" way — in a "nothing loads" way.
API keys and third-party services. Firebase, Stripe, SendGrid, push notification services, analytics platforms, cloud storage — your app likely uses several of these. Each one has an account, and each account is under someone's email. If they're under the developer's email and you lose access, you lose the ability to process payments, send notifications, view analytics, or store files. Make a list. Check every one.
Domain and DNS. If your app has a website or if your backend runs on a custom domain — who registered the domain? Where do the DNS records point? Domain registrations expire. If the developer registered it under their account and you don't have the credentials, you could lose the domain entirely.
Documentation. Does any exist? A README file, architecture notes, API documentation, deployment instructions — even informal notes in a shared Google Doc. Anything. If documentation exists, secure it now. If it doesn't, that's useful information too, because it tells you something important about what the next developer will be walking into.
The instinct here is to work through this list calmly and methodically. Resist that instinct — at least for the first 48 hours. The items at the top of this list are the ones you can lose permanently. Repository access and signing keys don't wait for you to get organized. Secure what you can lose first, then work outward.
Assessing What You Actually Have
Once the immediate triage is handled, you need to understand what you're working with. The codebase is sitting there. You can't read it — that's fine, you don't need to. But you do need to know whether it's something a new developer can work with or something that's going to cost you months before anyone can make meaningful progress.
The most reliable way to find out is simple: ask a developer to look at it. Not to fix anything, not to start working — just to evaluate. A competent developer can assess a codebase in two to three days and give you a clear picture of what they're dealing with.
Their reaction in those first 48 hours tells you almost everything you need to know. If they come back and say "this is workable — there are some rough spots but the structure is sound," believe them. That's genuinely good news. If they go quiet for a few days and then schedule a call to "discuss the situation," prepare yourself. That call is going to include phrases like "significant technical debt" and "we might need to talk about the overall approach."
There are a few signals you can check yourself, even without reading code.
Does the app have automated tests? You won't know what this means technically, but you can ask. If the answer is yes, that's a sign the previous developer was working with some degree of professionalism. Tests are a safety net — they catch things that break before those things reach your users. If the answer is no, it doesn't necessarily mean the code is bad. But it means the next developer has no safety net at all. Every change they make is a leap of faith.
Can a new developer get the app running on their machine within a day? This is a surprisingly revealing question. A well-organized project with a clear README and sensible setup instructions can be running locally within hours. A poorly organized one — missing environment variables, undocumented dependencies, build steps that only worked on the original developer's machine — can take a week just to get to the point where the app launches. If it takes a week to set up, the codebase has problems that go well beyond the developer's departure.
How current is the technology? If the app was built with a framework or language version that's two or three major versions behind the current release, updates are going to be painful regardless of code quality. Not because the old technology doesn't work — it might work fine — but because the ecosystem moves on. Libraries stop supporting old versions. Security patches stop arriving. The gap between where the app is and where it needs to be widens every month it sits untouched.
None of these signals require you to understand code. They require you to ask the right questions and listen carefully to the answers.
The Stranger Tax
Here's something that's important to understand before you hire the next developer, because it sets expectations for the first few months of the new relationship.
When a developer takes over code they didn't write, they pay a tax. Not a financial tax — a cognitive one. Every unfamiliar pattern is a puzzle they have to solve before they can work within it. Every undocumented decision is an assumption they have to verify, because acting on a wrong assumption in someone else's code can break things in ways that aren't obvious until they reach users. Every "clever" shortcut the previous developer took — the kind of thing that saved time in the moment but left no trace of why it was done that way — is a trap the new developer has to navigate around.
In a well-documented, well-structured codebase, a new developer becomes productive in about two weeks. They can read the code, understand the patterns, and start making changes with confidence. The structure itself acts as documentation — things are where you'd expect them to be, named in ways that explain their purpose, organized in a way that tells a story.
In a messy codebase — no documentation, no tests, inconsistent patterns, business logic scattered across files with no apparent organizing principle — that onboarding window stretches to three to six months. During that time, you're paying for the developer's hours while getting little visible output. They're not being slow. They're not being incompetent. They're doing archaeology. They're reading code that was written for an audience of one — the person who wrote it — and trying to reconstruct the reasoning behind hundreds of decisions that were never explained.
This isn't the new developer's fault. It's the cost of inheriting code without context. And it's worth knowing about upfront, because the temptation is to compare the new developer's pace to the old developer's pace and conclude something is wrong. Nothing is wrong. The old developer had context. The new one is building it from scratch.
The Conversation You Need to Have with the Next Developer
When you find someone — a freelancer, an agency, a new hire — there's a conversation that needs to happen before any work begins. Not a sales conversation. Not a scoping conversation. A conversation about how things will be done differently this time.
Ask them to give you an honest assessment before starting any work. A good developer will spend two to three days evaluating the codebase and come back with a clear picture: what's solid, what's fragile, what needs immediate attention, and what can wait. They should be able to explain this in plain language, without hiding behind jargon. If someone jumps straight into billable work without evaluating first, that's a signal — either they're not thorough, or they're more interested in hours than outcomes.
Ask about ownership from day one. The repository should be under your account, not theirs. The signing keys should be in your possession, with documented backups. The app store accounts should be under your email. The hosting credentials should be accessible to you. None of this is unusual to ask for. Any developer who pushes back on this is telling you something about how the engagement will end — and it won't end well.
Ask what happens when they leave. Not if — when. Every working relationship ends eventually. The answer you want to hear is something like: "Nothing dramatic, because everything is documented, the code is under your account, and any competent developer could pick this up." The answer you don't want to hear is silence, or a vague reassurance, or "we can cross that bridge when we come to it." You've already been to that bridge. You know what's on the other side.
Ask about documentation. Not documentation delivered at the end — documentation maintained throughout. A README that's updated when things change. Architecture decisions recorded when they're made, not reconstructed months later from memory. The goal isn't a novel. It's enough context that the next person — whoever they are, whenever they arrive — can understand what was built and why.
These aren't adversarial questions. A good developer will appreciate them, because they signal that you've learned from experience and that you take the engagement seriously. The developers who bristle at these questions are exactly the ones you're trying to filter out.
When the Code Is Worth Keeping vs. When It Isn't
This is the question that sits underneath everything else, and the honest answer is: it depends.
If the code works, users are satisfied, and the technology is reasonably current — keep it. Improve it incrementally. The stranger tax is real but temporary, and a good developer working within a functional codebase can make steady progress without the risk and cost of starting over.
If the code is a mess but the backend is solid — the database is well-structured, the API is clean, the server infrastructure is stable — consider rebuilding only the mobile layer. The backend is often the harder, more expensive part. If it works, preserve it. Replace the parts that are failing without touching the parts that aren't.
If nobody can understand the code, there are no tests, the technology is dead or dying, and every qualified developer you show it to recoils — starting fresh may genuinely be cheaper than trying to rehabilitate what's there. We wrote an entire article about making that decision, and the short version is: a rewrite is a real option, but it's a bigger undertaking than most people expect, and it carries risks of its own.
The worst approach is the one driven purely by emotion — either clinging to bad code because you've already paid for it, or torching everything because you're frustrated. Neither impulse leads to good decisions. Get an independent assessment. Let the evidence decide.
How to Prevent This From Happening Again
The most useful thing about this experience — and it might not feel useful yet — is that it teaches you exactly what to insist on in every future engagement. The businesses that come out of a developer departure stronger are the ones that change their practices, not just their personnel.
Repository under your account from day one. GitHub, GitLab, Bitbucket — it doesn't matter which. What matters is that the organization or account belongs to you. The developer gets access as a collaborator. When the relationship ends, you revoke their access. The code stays.
App store accounts under your email. Your Apple Developer account, your Google Play Console — these should be registered with an email address you control. The developer can be added as a team member with the appropriate permissions. They never need to be the account owner.
Signing keys stored in your secure location. Android keystores, Apple certificates — stored somewhere you can access, with passwords documented in a secure location that isn't the developer's password manager. Keep backups. If Google Play App Signing is available for your app, enroll in it — it stores the signing key on Google's servers, which removes the single-point-of-failure problem entirely.
Regular documentation updates. Not a documentation sprint at the end of the project. Continuous, lightweight documentation maintained alongside the code. A README that explains how to set up the project. Notes on architectural decisions. Instructions for deployment. This doesn't need to be extensive — it needs to be current.
Monthly access audit. Once a month, verify that you can still log into everything: app store accounts, hosting dashboards, domain registrar, third-party services, the code repository. This takes fifteen minutes. The alternative is discovering you've been locked out at the worst possible moment.
At least one other person should be able to build and deploy the app. Not theoretically — actually. Test it. Have someone other than the primary developer go through the process of pulling the code, building the app, and deploying it. If they can't, you have a bus factor of one, and you're exactly one departure away from being right back where you are now.
None of these practices are burdensome. None of them slow down development in any meaningful way. They're the kind of things that feel unnecessary when everything is going well and become the most important things you ever did the moment something goes wrong.
What Happens Next
This moment — the moment your developer leaves and you're holding an app you don't fully understand — feels like the worst possible position to be in. The uncertainty, the technical vocabulary you're not sure you're using correctly, the sinking suspicion that you should have asked more questions six months ago.
For many businesses, though, this turns out to be a turning point. Not because the situation is good — it isn't — but because it forces a clarity that didn't exist before. Before this happened, you trusted that someone else had it handled. Now you know what "handled" actually requires. You know which questions to ask. You know what ownership means in practice — not the legal abstraction, but the concrete reality of credentials, keys, accounts, and access.
The businesses that come out of this stronger are the ones that treat it as education, not just crisis. They secure their assets, they get an honest assessment, they hire someone who answers the hard questions instead of dodging them, and they build the relationship differently the second time around.
The developer left. The app is still there. What happens next is up to you — and the fact that you're reading this instead of panicking means you're already handling it better than most.