You paid for an app or a web platform. Work was moving. Then the replies got slower, the updates stopped, and now the person building it won’t answer. You have a half-finished product, a stack of invoices, and no clear picture of what you actually own.
It happens to new founders and established businesses alike, and it’s usually recoverable. The order you do things in matters more than how fast you do them. Access comes first, then an honest look at what exists, then decisions about the code and the people.
What should you do first?
Before you hire anyone new or argue about money, make sure you control everything the product runs on. A developer who has gone quiet can still hold the keys, and accounts tied to their email or their credit card can lapse without warning.
Send one calm, written message. Ask for access to the code and every account, a short handover note, and a date. Keep it factual. You want cooperation, and a heated message rarely gets it. Save copies of your contract, your invoices, and any messages about scope and payment.
If the developer has vanished completely, you still have options for most accounts, usually through each provider’s support process, but they take longer. Start now.
If your contract says who owns the code and what happens when the work ends, read that section first. If ownership is in dispute, an attorney can tell you what your agreement gives you. Most of what follows doesn’t need a lawyer, just persistence.
Which accounts do you need to get back?
Work through this list in order. For each item, write down where it lives, whose name and email it’s under, and who pays for it.
The code repository
The code usually lives on GitHub, GitLab or Bitbucket. You want the repository inside an organization or account you own, with you as an owner, not a collaborator someone else can remove. If it sits in the developer’s personal account, ask them to transfer it to yours. If you don’t know where the code is, look through invoices, emails and project tools for links, and check whether the hosting account shows which repository it deploys from.
Once you have it, download a full copy and keep it somewhere separate. That copy is your insurance.
Hosting and deployment
Find out where the app runs: Vercel, Netlify, AWS, Google Cloud, or a server somewhere. Then find out whose card pays for it. If the bill is on the developer’s card and they stop paying, the app goes offline, and you can lose anything that only existed on that server.
The domain registrar
The domain is one of the hardest things to replace. Log in to the registrar, or find out which one holds it, and check that the registrant contact and the account email are yours. If the developer registered the domain in their own name, ask them to transfer it to an account you control. Registrars have processes for ownership problems, but they take time, which is one more reason to start early.
App store accounts
If you have a mobile app, check whose Apple Developer and Google Play Console accounts it’s listed under. Both stores let an app move to another developer account, but the current account holder has to start the transfer. If you can’t get it moved, publishing under a new account usually means a new listing, starting over on reviews, and asking existing users to download a new app.
Third-party services and API keys
Most apps rely on outside services: payments through Stripe, texts through Twilio, email delivery, maps, login providers, AI APIs, analytics. Each one has an account, a billing method, and keys the app uses to connect. Build a list from the hosting settings, where these keys are usually stored as environment variables, and from the code itself.
Pay special attention to payments. Your Stripe account, or whichever processor you use, should be in your business’s name and pay out to your bank account. If it isn’t, fix that before anything else.
The database
Find out where your data lives (Supabase, Firebase, a Postgres server, MongoDB Atlas, Convex or similar) and who owns that account. Take a full export or backup now and store it somewhere you control. Your customer records are your responsibility, whoever set up the database.
Then lock it down
When you have owner access everywhere, remove the developer’s access and change the passwords. Then rotate the API keys, because the developer still has copies of the old ones. Do it one service at a time: create a new key, update it in the hosting settings, check that the app still works, then revoke the old key. Rotating everything at once is a reliable way to break a live app.
How do you tell what’s finished and what only looks finished?
A demo can look complete and still be a set of screens with nothing behind them. Buttons that don’t save anything, sample data typed straight into the code, a payment page that has never processed a real charge. The only way to know is to test it.
Have someone check these, ideally someone who didn’t write the code:
- Can someone new build and deploy it from the repository? If only the original developer’s laptop can produce a working version, the project is less finished than it looks.
- Does the code in the repository match what’s live? Unmerged branches and uncommitted work are common after a sudden exit.
- Do the main flows work end to end with real data? Sign up, log in, password reset, the core thing the app does, payments in test mode, notifications, and the admin side.
- What happens when things go wrong? Bad input, a dropped connection, a payment that fails.
- Are there obvious red flags in the code? Passwords or keys written into the code, a database anyone can read, large sections marked “TODO”.
- What does the commit history say? When the last real work happened, and whether recent commits were features or quick patches.
Sort what you find into three lists: works, half-built, missing. That plain written account is worth more than any progress estimate the previous developer gave you, and it’s the only sound basis for a quote.
What should a proper handover include?
If the developer is cooperating, ask for these. If they aren’t, this is the list a new developer will have to piece together from the code:
- Every account and service the product uses, whose name it’s in, and what it costs each month
- How to run the project locally and how to deploy it
- The names of the environment variables and where each one is set
- The database structure, any migrations, and where backups go
- Known bugs, unfinished features, and anything they meant to come back to
- Design files, plus any paid themes, libraries or licenses
Credentials should come over through a password manager, never pasted into an email or a text. A thin or empty handover is common. It slows the next developer down, but it doesn’t sink the project, because the code itself still shows how most of it works.
Should you keep the existing code or rebuild?
Nobody can answer this honestly without reading and running the code. Anyone who says “it’s all fine” before running it, or “we’ll have to start over” before reading it, is guessing.
Continuing usually makes sense when the project uses a standard, well-supported framework, builds and deploys cleanly, the main flows mostly work, and the way the data is organized fits what the product needs to do.
Rebuilding a part usually makes sense when that piece can’t be built at all, depends on tools that are abandoned or obscure, has security problems baked into its structure, or is so tangled that every small change breaks something else.
In practice the answer is often a mix: keep most of it and rebuild specific pieces. Ask whoever assesses it to give you the reasoning piece by piece, in writing, so you can see why each part stays or goes. That’s how we start every app rescue, including the stalled build we took over for a travel planning startup: find out what’s actually finished before anyone talks about price or rewrites.
How do you choose who takes over?
You’re hiring for the same job that just went wrong, so look for the habits that would have prevented it.
- They assess before they quote. A fixed price to “finish the app” without seeing the code isn’t a real number.
- They work in your accounts. They should accept an invite to your repository and hosting, not ask you to move things into theirs.
- They scope in phases. Each phase has its own price and a finish line you can check.
- They show working software often. A short demo every week or two, on a staging site you can click through yourself.
- They can tell you how they’d hand it off. Ask what you’d get if you parted ways tomorrow. A good answer is specific.
- They’re honest about the stack. If the app is built on something they don’t know well, they say so.
Ask how they handle your customers’ data, too, and expect the answer in writing. Here’s how we handle client data, as one example of what that looks like.
How do you keep this from happening again?
Most of the damage when a developer leaves comes from three gaps. Each one is cheap to close at the start of a project.
Accounts in your name from day one. You create the repository organization, the hosting account, the domain, the app store accounts and the service accounts, with your email and your card. Then you invite the developer in. When they leave, you remove them, and nothing has to move. Our developer ownership checklist lists every account and what a proper handoff includes.
Regular access to the repository. You don’t need to read code to benefit. If you can see work being committed every week, and each update points to what changed, silence shows up in days instead of months.
Phased payments tied to shipped pieces. Pay for features you can use on a staging site, not for hours or for a progress estimate. If a phase isn’t delivered, you haven’t paid for it, and what you have paid for already works.
Add a written agreement that says you own the code and that the developer will hand over access and documentation when the work ends. It costs nothing to include up front, and it’s much harder to add later.
Want someone to look at what you have?
If your build has stalled, start with an app rescue assessment. A person takes a first look at what’s live, what you can access and who controls the accounts, then sends you a plain recommendation. If you need help getting access back, that comes first.
When you’re ready to finish the build, here’s how we approach custom software: phased scope, accounts in your name from day one, and working software you can see early.