Key Takeaways
A founder’s ordered recovery sequence for a ghosted build, with the platform deadlines that decide what you can still get back.
- Account control comes before code. Without the root credential, the code is often unreachable no matter who paid for it.
- AWS states plainly that Support “can’t change the credentials associated with an account for any reason.” Nobody can escalate past that.
- ICANN’s transfer policy imposes a 60-day inter-registrar transfer lock after a change of registrant, and the opt-out only works before the change.
- Apple will not transfer an app that has never had a released version, so a pre-launch ghosting has no transfer route at all.
- Legal is the last lever. The filing fee is the cheapest part and the money is usually already spent.
You cannot talk your way back into an account you do not control. Amazon’s own sign-in troubleshooting page says it directly: “AWS Support also can’t change the credentials associated with an account for any reason.”
That one sentence reorders everything a founder does next. Most advice for this situation starts with the code, because the code feels like the asset. The code is downstream. Control is upstream, and control lives in a handful of accounts you probably cannot list from memory right now.
Here is the order. Recover account control first. Recover the code second. Assess what you actually have third. Treat legal as the last lever, not the first. That sequence is not a preference, it is forced by the fact that each platform runs its own deadline and some of them expire quietly.
Map the accounts before you chase the code
Write the list first. You do not own a project, you own a set of accounts, and each one has exactly one party holding the root credential.
Quick Verdict: Do not start with the code. Start with a written list of every account the build lives in and who holds each root credential, because that list decides what is recoverable at all. Velcod runs MVP development with that list as a named deliverable, and the MVP build process covers how a build should be set up so this cannot happen to you.
Call it THE ACCOUNT MAP. One row per account, one named human per row, one honest answer on whether you can get in without the developer.
| Account | What it controls | Who usually holds it | Recoverable without them |
| Domain registrar | The name, DNS, email routing | Developer, far too often | Only if you are the registrant |
| Code host | The repository and its history | Developer’s personal account | Only if the org is yours |
| Cloud or hosting | The running application and data | Whoever opened it | Only via the root email |
| App Store Connect | The iOS listing and builds | Developer’s team | Only inside their team |
| Google Play Console | The Android listing | Developer’s account | Only with their cooperation |
| Payments | Live revenue and customer records | Usually you, thankfully | Usually yes |

The reason this row order matters is the cloud row. Amazon’s guidance points you back to the email address on the account, and suggests restoring a deleted mailbox or setting up a catch-all, both of which only work if you own the domain. If your developer used a personal address on a domain they control, that account is theirs in practice.
Do this: Open a blank document and write the six rows above with real names in the third column. Leave gaps where you do not know. The gaps are the problem.
The clocks that are already running
Some of these deadlines started the day the developer went quiet, and nobody sends you a reminder.
Call it THE CLOCK LIST. Three of the clocks are published, specific, and easy to miss.
| Platform | The clock | What it costs you |
| Domain registrar | 60-day inter-registrar transfer lock after a change of registrant | Two months of being unable to move the domain |
| Code host | 90 days to restore a deleted repository | After that the history is gone |
| Apple | No released version means no transfer at all | The listing cannot move, only be rebuilt |
ICANN’s Transfer Policy states that “The Registrar must impose a 60-day inter-registrar transfer lock” following a change of registrant, and that a registrar may allow the holder to opt out “prior to any Change of Registrant request.” The opt-out is only available before the change, which means it is already too late to choose it.

The harder clause sits earlier in the same policy. It states that “The Registered Name Holder is the only party that has the authority to approve or deny a transfer request.” If the developer is listed as the registrant, the policy itself is what blocks you, not their bad behavior.
A change of registrant also needs confirmation from the prior registrant through a secure mechanism. Someone who has stopped answering email cannot confirm anything, so the route stays shut while they stay silent.
Do this: Run a public WHOIS lookup on your domain today and read the registrant field. That single field tells you whether the domain is a conversation or a fight.
What you can take back without the developer
Some assets come back on your own authority. Others require a signature you are not going to get. Know which is which before you spend a week on the wrong one.
Repositories are the most recoverable thing on the list, and only if the organization is yours. GitHub’s documentation on restoring a deleted repository states that “A deleted repository can be restored within 90 days,” that “Organization owners can restore deleted repositories that were owned by the organization,” and that “Restoring a repository will not restore team permissions.”

Mobile listings are the least recoverable. Apple’s app transfer criteria require that “The app must have at least one version that was released to the App Store,” and that neither account is “in a pending or changing state.” Google’s process for transferring apps to a different developer account needs “the registration transaction ID for your account and the target account,” and the original account is the one that submits.
Both routes therefore need the developer to act. Neither is something you can do alone, and that is worth knowing on day one rather than day twenty. If the build sits on a visual platform rather than in a repository, the mechanics change again, and moving off a no-code platform is its own piece of work with its own export limits.
Do this: Sort your account map into two columns, yours and theirs. Spend your first week only on the yours column.
Read the repo for state, not for quality
Once you have the code, resist the urge to ask whether it is good. Ask where it stopped.
Quality is a judgment that needs a senior engineer and a week. State is a fact you can establish in an hour from the commit history. Open the repository’s activity view and read the shape of it: when commits stopped, whether they cluster or trail off, and whether the last month is features or small fixes.

Trailing commits are the common pattern and the useful signal. Work slowing for six weeks before the silence usually means the developer was already struggling, not that they vanished suddenly. That changes what you believe about the last status update you were given.
Then compare the state you found against what a build of this size normally needs. A feature that is half done at month four reads differently once you know the typical build timeline for the thing you commissioned.
Do this: Screenshot the commit graph with the final date visible and save it. It is the most useful single artifact in the whole recovery.
Decide salvage or restart on evidence
This is the decision founders delay longest, and the delay is the expensive part. Set the criteria before you look, then look once.
Salvage is right when the data model is sound and the gaps are features. Restart is right when the data model is wrong, because every feature built on top of it inherits the error. That is the dividing line, and it is a narrower question than asking whether the code is any good.
| Evidence you find | Reasonable call |
| Schema matches the product, features missing | Salvage and finish |
| Tests exist and run | Salvage, you can change things safely |
| No tests, but the schema holds | Salvage with a hardening pass first |
| Schema cannot represent the product | Restart, salvaging costs more |
| No deploy process anyone can run | Treat as a restart until proven otherwise |

Price both before you commit to either. A restart quoted honestly is often closer to the salvage number than founders expect, because a salvage carries weeks of reading someone else’s work before anything ships. Our published MVP cost ranges are the same numbers we would quote you here, and they are the right baseline for this comparison.
Do this: Write the salvage criteria down before anyone reviews the code, so the review tests a hypothesis instead of producing an opinion.
Legal is the last lever, not the first
Legal action is a real option and it is almost never the one that gets your product finished.
The predictable costs are small and published. The federal courts’ District Court Miscellaneous Fee Schedule sets the administrative fee for filing a civil action at $55, effective 1 December 2023, on top of the statutory filing fee. Everything after that line is counsel, discovery, and the separate problem of collecting on a judgment.
That is the part founders underweight. A judgment is a piece of paper, and a developer who stopped replying to email is rarely a defendant with assets waiting to be seized. Meanwhile the clocks in section two keep running.

There is one narrow case where counsel belongs early. If the developer is actively holding a live production system hostage, or is threatening to delete it, that is worth a lawyer’s letter the same week. Short of that, money spent on finishing the product usually beats money spent on recovering the last payment, and our client case studies are the ones that ended in a shipped product rather than a filing.
Do this: Get a one-hour consultation to understand your position, then decide. Do not open a case before the account map is finished. None of this is legal advice.
What to put in the next contract
The clauses that would have prevented this are short, cheap, and almost never in a first contract.
Five of them do most of the work. Accounts are opened in your name from day one, with the developer added as a collaborator. The registrant on the domain is you. The repository lives in an organization you own. The root credentials sit in a password manager you control. And a written handover is a deliverable with a date, not a favor at the end.

None of these clauses cost a vendor anything if they intended to behave well. That is what makes them a useful test during a sales conversation. A builder who resists owning nothing is telling you something before you sign.
The handover clause is the one that gets dropped most often and matters most. It should name the accounts, the credentials, the deploy steps, and a date. If you are choosing who to work with next, the way a development company answers that question is more informative than their portfolio.
Do this: Add the five clauses to your next agreement before you discuss price. They are easier to agree to when nothing is at stake yet.
What this will not fix
An ordered recovery improves your odds. It does not create access that policy forbids.
If the developer is the registered name holder on your domain and never replies, the transfer route stays closed. ICANN’s policy makes their confirmation a requirement, and no amount of escalation at the registrar changes a consensus policy. Your realistic option is a different domain, which costs you the SEO history and the email continuity.
The same holds for a cloud account on an email address you do not control. Amazon’s guidance offers email recovery paths, all of which depend on owning the domain, and then points you to Support, which cannot change credentials. That is a closed door described politely.
We also cannot tell you how long a recovery takes. It depends on which rows in your account map are yours, whether the repository still exists, and whether the developer resurfaces. Anyone quoting you a timeline before seeing the map is guessing.
The first 48 hours, in order
Six actions, in this sequence. Nothing here needs the developer’s cooperation.
- Run a WHOIS lookup and read the registrant field.
- Write the account map with real names, leaving the gaps visible.
- Change passwords and revoke sessions on every account you can still sign into.
- Export the data you can reach today, including the database and any customer records.
- Check whether the repository exists, and note the date if it was deleted.
- Save a screenshot of the commit graph with the final commit date legible.
We run this same list on day one of every rescue. It sits at the opposite end of the work from our three-week MVP builds, and it is the step that makes every later decision cheaper.
Do these before you send a single further email. Every one of them is reversible, cheap, and useful whether or not the developer comes back.
Where we fit
We take over builds that stalled, and we are honest that roughly half of what we see is a salvage and half is a restart.
What we do first is the account map, because it is the only step that is the same in both cases. Velcod builds MVPs in three weeks in real code, and on a rescue the first deliverable is not code, it is a written list of what you control, what you do not, and which clocks are running. You keep that document whether or not you work with us.
This is not the right call for everyone. If your build is nearly done and the original developer is merely slow rather than gone, a conversation is cheaper than a handover. If there is live revenue and a hostage situation, you need a lawyer before you need us.
If you want the map done this week, book a call with us and bring whatever logins you still have. You will leave with the list, whoever finishes the build.
Frequently Asked Questions
Can I get my code if the developer will not respond?
Sometimes. If the repository sits in an organization you own, you can recover it yourself, including a deleted one within GitHub’s stated 90-day window. If it sits in their personal account, you generally cannot, and the practical route is reconstructing from whatever builds, exports or backups you already hold.
Who owns the code if I paid for it?
Payment and ownership are separate questions settled by your contract, and ownership does not grant access. Even a clear assignment clause does not let a platform hand you an account the developer controls. Read the agreement, then treat access as a separate problem solved through the account map rather than through the ownership argument.
Should I sue my developer?
Rarely as a first move. The published court fees are small, but counsel, discovery and collecting on a judgment are not, and a judgment does not finish your product. Get one hour of legal advice to understand your position, finish the account map, then decide. Reserve urgency for a live system being held hostage or threatened with deletion.
How do I take over the App Store listing?
Only through a transfer the developer initiates, and only if the app already has a released version. Apple’s criteria also block transfers while either account is in a pending state. If the app never shipped, there is no transfer route, and you will be creating a new listing under your own team.
What stops this happening again?
Account ownership in your name from day one, you as the domain registrant, the repository in your organization, root credentials in your password manager, and a handover written as a dated deliverable. Any builder planning to behave well agrees to all five without friction, which makes them a useful question during a sales call.
Resources
- Transfer Policy, ICANN. The mandatory 60-day inter-registrar transfer lock after a change of registrant, the registrant’s exclusive authority over transfers, and the confirmation required from the prior registrant.
- Restoring a deleted repository, GitHub Docs. The 90-day restore window, who is permitted to restore, and what a restore does not bring back.
- App transfer criteria, Apple, App Store Connect Help. Every condition an app must meet before it can move accounts, including the released-version requirement.
- Transfer apps to a different developer account, Google Play Console Help. The registration transaction IDs required from both accounts, who submits and who approves, and what does not transfer.
- Troubleshooting AWS account sign-in issues, Amazon Web Services. The email-based recovery paths and the statement that Support cannot change an account’s credentials for any reason.
- District Court Miscellaneous Fee Schedule, Administrative Office of the U.S. Courts. The $55 administrative fee for filing a civil action, effective 1 December 2023, and the exemptions that apply.
M. Sabir Junaid
Founder • CEO
M. Sabir Junaid is founder and CEO of Velcod, the senior product studio. He leads product and delivery across MVPs, SaaS platforms, and mobile apps — system architecture, no-code and low-code engineering, and AI integration. An official Bubble partner, Sabir has shipped products across fintech, marketplaces, edtech, and creator platforms. He works with founders raising pre-seed to Series A who need a product built to launch and scale in weeks, not a six-month agency build.
Share
- Previous
- Next
Ready to build?
Your idea, live in 3 weeks.
Book a free strategy call and get a fixed-price roadmap for your MVP, SaaS, or app.