The message you do not want to send twice: "Hey, just checking in, are you there?" A developer going quiet is one of the more stressful things that can happen to a founder, because your product is often sitting in that person's hands and you do not know if they are sick, overloaded, quietly quitting, or gone for good. The move is to act calmly and in a specific order, protect your assets first, and avoid the two mistakes that make it worse: panicking, and doing nothing.
Key Takeaways
- Distinguish a short, explainable silence from a real disappearance before you react.
- Secure access and code first, while you still can, not after.
- Have a written record of what only they know, so a disappearance is a setback and not a catastrophe.
- The best fix is prevention: an engagement structured so no single person can take your product hostage.
First, Read the Silence
Not every quiet day is a crisis. A developer heads-down on a hard problem, in a different timezone, or dealing with something personal can go quiet for a day or two and reappear with work done. So start by reading the silence honestly. How long has it actually been, against how they normally communicate? Did anything change (a payment issue, a tense conversation, a missed deadline they might be avoiding)? A pattern of steady communication that suddenly stops is a different signal from someone who was always sporadic. Give a reasonable, explicit window ("I need to hear from you by end of day tomorrow"), and watch whether they treat it seriously.
Secure Your Assets Before You Need To
If the silence stretches past that window, protect the things you cannot afford to lose, and do it while you still have the access to do so. Make sure you, not the developer, own the repositories, the cloud accounts, the domain, and the credentials. If everything currently runs through their personal accounts, that is the real emergency, and it is why the securing has to happen early rather than after they are fully gone.
| Asset | The safe state |
|---|---|
| Code repositories | Owned by your org, not their personal account |
| Cloud / hosting | Your account, your billing |
| Domains + DNS | Registered to you |
| Credentials / secrets | In your vault, rotatable by you |
| Knowledge | Documented, not only in their head |
A Concrete Version
A founder's solo contractor stopped replying for a week during a launch. The panic was not that the person had gone quiet. It was that the app deployed from the contractor's personal cloud account, the repo was under their personal handle, and the founder had no admin access to either. A week of silence turned into a genuine hostage situation, because the setup had made one person a single point of failure for the entire product. The founder eventually rebuilt access the hard way, but the lesson was permanent: the time to own your own accounts is the day you start, not the day someone disappears.
The Honest Counterpoint
Do not torch the relationship on day two. Firing off an angry ultimatum or revoking a working developer's access over a normal quiet stretch is how you turn a small communication gap into an actual departure, and word travels among good engineers. Most silences have a boring explanation. Give a fair, clear window and secure your assets quietly in parallel, without accusing anyone. Reserve the hard steps for a real disappearance, and even then, stay professional, because you may still need their cooperation to transfer what they know.
Frequently Asked Questions
How long should I wait before treating it as a real problem?
Judge it against their normal pattern, not a fixed number. A day of quiet from someone usually responsive is worth a direct check-in with a clear deadline; a week past an explicit window is a disappearance you act on.
What is the first practical thing to do?
Confirm you own and can access the repositories, cloud accounts, domain, and credentials. If any of those run only through the developer's personal accounts, fixing that is the priority.
How do I prevent this next time?
Structure the engagement so no single person holds your product. Own the accounts from day one, keep documentation current, and use a provider or arrangement with a replacement path so one silence cannot stall you.
The Bottom Line
When a developer goes dark, read the silence honestly, secure the assets you cannot lose while you still can, and avoid both panic and paralysis. The deeper fix is structural: own your accounts and knowledge from the start so no one person can take your product hostage. For related situations, see how to hire a developer after a bad experience and who owns the code a contractor writes. See available engineers.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
