My developer left / the first week
Your developer left. The app is still running. Start here.
Maybe they resigned properly. Maybe the freelancer stopped answering three weeks ago and you just admitted it to yourself. Either way you now own a piece of software you cannot read, and every article you find is written for engineering managers with a team. This one is written for you: the owner, alone with the app.
The short answer
Do not panic and do not rush to hire. In week one, inventory your access: repo, domain, hosting, database, keys, payments, email. Secure what is yours, change almost nothing, and confirm nothing is broken or exposed. Then decide calmly whether you need a rescue or just a caretaker who stays.
One more reassurance before the checklist: a working app does not decay in a weekend. If it ran yesterday it will very likely run next week. The genuine week-one risks are narrow and specific: a hosting bill on the departed developer's card, credentials only they hold, or a security hole nobody ever checked for. Everything below is aimed at exactly those three.
The access inventory. Seven accounts, one afternoon.
Open a document and go through these seven in order. For each one write down: whose account it is on, whether you can log in right now, and whose card pays for it. That document is worth more to your next developer than any handover call.
What to lock down now: anything that is yours but shared. Change the passwords on accounts registered to your email, turn on two-factor authentication, and remove the departed developer's access from Stripe and your registrar. If they left badly and held admin on accounts you own, do this the same day.
What not to touch: the code, the database contents, DNS records, and any API key you cannot trace. Rotating a key the app depends on takes the app down, and week one is the worst possible time to learn which key does what. The live system kept working the day they left. Your job is to keep it boring until someone competent is looking at it. If they left on decent terms, one polite email requesting a repo transfer and a list of accounts beats any amount of forensics.
Do you own the code? Plain language, not legal advice.
This is the question that keeps owners up at night, so here is the honest shape of it. None of this is legal advice; for anything contested, a real lawyer beats a web page.
By default, US copyright belongs to whoever wrote the code. For an employee, work done within the scope of the job generally belongs to the employer automatically. For a contractor or freelancer, it generally does not: paying the invoice buys you the work product, not automatically the copyright, unless a written agreement assigns it to you. This surprises almost every non-technical founder, and it is why the phrase "work for hire" appears in decent contracts.
So check three things. One: is there a signed contract, and does it contain an IP assignment or work-for-hire clause? If yes, you are likely fine. Two: if there is no contract, do you have an invoice and payment trail showing the work was commissioned by you? That does not settle copyright, but combined with possession of the code it puts most small products in a workable position, since at minimum you generally have a strong claim to a license to keep using what you paid for. Three: where does the code physically live? A repo on their personal account is an access problem layered on top of the legal one, and the access problem is usually the more urgent and the more fixable of the two.
Practical note: most departures are not hostile. A short, warm message asking for a repository transfer, a credentials list, and a final invoice settles the majority of these situations in a day. Save the legal question for the minority where someone is actually withholding your business from you.
Find out what you actually have.
The most expensive mistake in this situation is hiring a replacement to work on a codebase nobody has assessed. You end up paying discovery rates for weeks while a stranger reads code, and you cannot tell whether their alarming report is the truth or a sales pitch. Assess first, hire second.
An assessment answers four questions. Is anything exposed right now, like an open database or keys shipped to the browser? Is anything quietly failing, like error rates or a dead email integration? What is the true inventory: which services, which accounts, which moving parts? And how hard will this codebase be for a new person to operate? You can start yourself for free: our Leak Check reads your live site from the outside and flags the obvious exposure in about a minute, no signup. If your app was built with an AI tool like Lovable or Bolt, the platform-specific checks on our is-Lovable-safe and is-Bolt-safe pages cover the failure modes those builders ship with.
The deeper version is Ship Check, a $299 flat-price audit: an agent fleet reads the app overnight and a senior engineer ranks what it finds into what is dangerous, what is urgent, and what can wait, each finding with a proof you can re-run. For an inherited codebase that report doubles as the handover document your developer never wrote. Whoever you eventually hire, walking in with an independent assessment changes the conversation from "trust me, it is bad" to a ranked list you both can see.
Rescue, or caretaker search? They cost very different amounts.
Every developer-left situation resolves into one of two shapes, and naming yours sets your budget.
It is a rescue if something is broken or exposed: the app is down, payments fail, users are complaining, or the assessment found an open database or leaked credentials. Rescues justify speed. Our own fix tier, Ship Fix, closes the dangerous findings at a fixed $4,000 to $15,000 scope agreed up front. If the app was hacked rather than merely abandoned, the incident playbook on our app-hacked page comes first, then the fix.
It is a caretaker search if the app works and simply has nobody watching it. This is the more common case and the less urgent one, which matters, because urgency is what pushes owners into bad hires. A working app buys you two or three weeks to choose well. What you are shopping for is ongoing operation: monitoring, updates, small fixes, and a person who answers. That is what our Continuum tiers are, from $49 to $199 per month for watching, $500 to $1,500 per month for active care, up to $3,000 to $15,000 per month for a real technical partner. For what ongoing coverage should cost and why, see the maintenance cost breakdown.
And if neither of us is the right fit, the market has honest options at both ends. As of July 2026, Afterbuild Labs runs a fixed-menu rescue line that starts under $500, a $49 async repo audit and a $299 emergency triage, which is the right buy for one known bug. At the other end, Justin McKelvey takes complex production rescues listed at $25K to $50K over 4 to 8 weeks, the right call when serious revenue is on the line and the damage is deep. Matching the size of the response to the size of the problem is most of the game.
Pick a successor who stays. Here is what to screen for.
You are on this page because the last arrangement ended. So the real question is not "who can code" but "who will still be here in year three." The market answers with the wrong proof: firms cite their founding year, freelancers cite career length. A twenty-year-old agency can still hand your account to a rotating cast of juniors. The number that predicts your experience is different: how long do clients keep choosing the same operator, voluntarily, when they could leave? Ask every candidate for their longest continuous client relationship and whether you can hear about it. Ours is on the proof page: the longest engagement there runs 15+ years with the same owner, growing from a WordPress site into the custom platform that now runs the business. That is the kind of answer you are listening for, from us or from anyone else.
Then screen against hostage dynamics, because staying power without clean terms is just a slower version of the problem you have now. Three tests. Access: the repo, registrar, hosting, and keys live in accounts you own, and the new operator works inside them, never the reverse. Documentation: written down as part of the work, so the next transition, and there is always eventually a next transition, is an afternoon instead of a crisis. Exit terms: what happens at the end of the relationship is agreed in writing at the start of it. A candidate who resists any of these is telling you, politely, how this ends.
Notice these tests are exactly the inventory you built in week one. The situation that brought you here, access scattered across someone else's accounts, nothing documented, no exit terms, was not bad luck. It was the default arrangement, and it is the one thing you get to fix permanently in the hire you are about to make. If the departure came with a pile of AI-generated code nobody documented, our vibe code handoff guide covers how a competent successor takes over an undocumented codebase. And if what you really need is ongoing technical judgment rather than hands on keyboard, the fractional CTO pricing guide maps that market honestly too.
Developer left, straight answers.
You inherited an app.
You do not have to run it alone.
If your situation needs a bigger specialist or a smaller one, we will say so and name them.
Matt
Last updated: July 2026. Competitor prices checked against their live sites as of July 2026.