Your Developer Ghosted You. Your App Is Broken. Here's Exactly What to Do Next.

You're Not the Only One This Happened To

Every week, threads appear across r/entrepreneur, r/smallbusiness, and r/startups with some version of the same story: 'I paid a developer $15,000 and they stopped responding.' Or: 'Our agency delivered something that kind of works, but we can't add features without everything breaking.' Or: 'We've been in development for eight months and there's still nothing live.'

These aren't edge cases. Industry research consistently shows that 60–70% of outsourced software projects run into significant problems — missed timelines, cost overruns, quality failures, or outright abandonment. The reasons vary: underfunded freelancers who took on too much, agencies that won the project with a low bid and cut corners to stay profitable, communication breakdowns that compounded into scope disputes, or simply a mismatch between what was promised and what the team was capable of delivering.

If you're sitting with a broken build, a ghosted developer, or a product that technically 'works' but can't actually run your business — this post is the practical guide to what happens next. There is a way through. But the path forward requires a clear-eyed look at where you are before you can make any good decisions about where to go.

The Four Most Common Ways Software Projects Fail

Understanding the failure mode matters because it shapes what's recoverable and what isn't. The four patterns that account for the vast majority of failed projects are each worth naming.

The ghosting or abandonment scenario is the most psychologically brutal. A freelancer or small agency takes your deposit, does some early work, and then becomes increasingly unreachable. Responses slow to days, then stop entirely. You may have partial code, you may have nothing, and you may not even have access to what was built because it lives in their accounts, not yours.

The delivered-but-broken scenario is more common than ghosting, and in some ways harder to deal with because there's an invoice marked paid and a product that technically exists. It just doesn't do what you need it to do — buggy, slow, impossible to extend, or built on architectural decisions that mean every new feature is a crisis. The agency considers the engagement complete. You consider it a loss.

The scope-creep-into-bankruptcy scenario starts with a reasonable quote and ends with a project that has consumed three times the original budget with no clear finish line. The agency kept finding 'unknowns' and adding change orders. You kept approving them because the alternative was to walk away from everything already spent. This pattern is common in projects where the original scoping process was inadequate.

The IP-trap scenario is one many clients don't discover until they try to leave. The code is technically yours, but everything runs in the agency's cloud accounts, under their API keys, deployed through their pipelines, with documentation that only they can interpret. You legally own the software and operationally cannot touch it without them.

First Steps: Secure Your Assets Before You Do Anything Else

Regardless of the failure mode, the immediate priority is the same: take inventory of what you control, and lock it down before any relationship officially ends. This sounds obvious, but it's the step most business owners skip in the heat of the moment — and it causes significant downstream problems.

Codebase access: confirm that your source code repository lives in an account you control — your own GitHub, GitLab, or Bitbucket organization, not the developer's with you as a guest. If it doesn't, request a full export immediately. If the developer is still reachable, make this the first and most urgent ask. If they're not, check whether you have any version of the code — even older builds, local copies, or export files — that gives you a starting point.

Infrastructure ownership: identify every cloud service, hosting account, domain, and third-party API the project uses. AWS, Google Cloud, Vercel, Heroku, Stripe, Twilio, Sendgrid — any of these running under the developer's account means you are one relationship breakdown away from your product going offline with no warning. Transfer ownership of every account you can. Change credentials on everything immediately.

Documentation and credentials: request a full list of credentials, environment variables, third-party service accounts, and any deployment documentation that exists. Even if the project is in bad shape technically, having this information is the difference between a difficult rescue and starting from zero.

Financial options: if you paid by credit card and received no working deliverable, a chargeback may be available. If the amount is significant and you have a signed contract with defined deliverables, small claims court is a realistic option in most jurisdictions for amounts under $10,000–$25,000. This is worth pursuing in parallel with the technical recovery, not instead of it.

Should You Rescue or Restart? How to Actually Decide

This is the question every business owner with a failed build faces, and the instinctive answer is usually wrong in one direction or another. Some founders want to rescue everything because of the sunk cost. Others want to burn it down and start over because of how they feel about the previous engagement. Neither instinct is a good guide.

The right answer comes from an objective technical audit, not from emotions or assumptions. The purpose of the audit is to answer three questions: Is the architecture fundamentally sound, or does it have structural problems that will make every future change expensive? How much of the existing code is actually usable — tested, reasonably written, with no obvious security vulnerabilities? What would it cost to rescue the existing work versus the cost of a clean rebuild, given your specific requirements?

Rescue makes sense when the architecture is defensible, when a meaningful portion of the code is working and trustworthy, and when the remaining work is well-defined enough that a new team can estimate it accurately. This is often the case when a capable developer ran into capacity or communication problems rather than fundamental skill issues.

Rebuild makes sense when the codebase has no coherent structure, when security vulnerabilities are foundational rather than patched, when the technology choices are so outdated or inappropriate that maintaining them will cost more than starting fresh, or when the requirements have changed significantly enough that the original build is solving the wrong problem.

A credible technical audit takes one to three days and should cost $500–$2,000 depending on scope. It is not optional. Skipping the audit and making the rescue-vs-rebuild decision based on gut feel is how you end up spending another $30,000 on a project that needed to be restarted from day one.

Finding a Development Partner Who Won't Repeat the Pattern

The experience of a failed project is genuinely useful — if you use it to change the evaluation criteria for your next partner. Most people who get burned had warning signs available before they signed the contract that they didn't know how to read. The evaluation framework for your next engagement should be built around those signals.

Process over portfolio: the most important thing you can learn about a prospective agency is how they work, not what they've built. Ask specifically: what does your discovery phase look like? How do you handle scope changes? What do you deliver at project completion, and how is the handoff structured? A team that can answer these questions in specific, concrete terms has done this before. A team that pivots to showing you case studies instead of answering has not.

References from rescue engagements specifically: if you have existing code that needs to be assessed and either rescued or rebuilt, look for an agency with explicit experience inheriting failed projects. Rescuing a broken codebase is different from building from scratch — it requires the ability to audit unfamiliar code, make judgment calls about what to keep, and communicate honestly about what they're inheriting. Ask directly: have you taken over a failed project before? What was your process?

Fixed deliverables with milestone-based payments: avoid engagements where payment is purely time-and-materials with no clear milestone structure. The payment structure should reflect the delivery structure: defined phase, defined deliverable, defined payment. This creates natural checkpoints where both parties can assess progress and course-correct before problems compound.

Transparent communication norms: the most common proximate cause of project failure is communication breakdown — either the developer going quiet, or the client and developer misaligning on scope without catching it early. Ask how your new partner handles it when work is behind schedule, when a technical problem arises that affects the timeline, or when the team isn't sure how to build something. The answer reveals more than any portfolio.