AppMatic Tech rescues stalled and failed software projects by taking over inherited iOS, Android, and web codebases written in Swift, Kotlin, Flutter, React, Node.js, and Laravel, stabilising them, paying down technical debt, and driving them to a shippable release. AppMatic Tech is based in Ahmedabad, India, and has shipped 330+ products with an 83% client retention rate since 2017.
A McKinsey and University of Oxford study of large software projects found that they run on average 45% over budget and 7% over time while delivering 56% less value than predicted, and the Standish Group's long-running CHAOS research has repeatedly put the share of software projects that are cancelled before delivery at roughly one in three. Behind those numbers sits a specific and common situation: a founder has paid an agency for months, the app is half built, the milestones have stopped, and the messages have gone quiet. That situation is more recoverable than it feels, and the worst move is to panic into a full rebuild before anyone has read the code.
This article is the process AppMatic Tech uses when a founder arrives with a stalled build and a non-responsive agency. It covers the first week, the audit, the rescue-versus-rebuild decision, a real takeover that shipped, and what the work costs.
Key takeaways
A stalled app is a recoverable asset until an audit proves otherwise. Secure it first, diagnose it second, and only then decide whether to rescue or rebuild.
| Point | Detail |
|---|---|
| Secure access before anything technical | Confirm you own the repository, app store, cloud, domain, and design files in your name before commissioning any new work. |
| Most stalled builds are rescued, not rebuilt | A working codebase with technical debt is usually faster to stabilise and finish than to restart. EYVA proved this across an eight-month takeover. |
| The audit is the product of week one | A written stabilisation plan with a prioritised fix list is what turns an unknown codebase into a fixed-scope, fixed-price engagement. |
| Rebuild only on architecture or ownership grounds | Restart when the architecture cannot carry the roadmap, or when you cannot legally use the code, not because the code is unfamiliar. |
| Ownership is contractual, not who typed the code | IP assignment and account ownership decide what you can keep. Verify both early. |
| A takeover moves faster than the original build | A stabilised, well-audited codebase lets a competent team ship in months what a stalled engagement failed to finish over a longer period. |
Why do app projects fail with an agency?
Projects rarely fail for the reason the founder is told. The final message usually mentions a resourcing problem or a scope disagreement, but the failure was underway long before that. The recurring causes are consistent:
- No frozen scope. The build started before the specification was stable, so every week added work that no one priced, and the agency slipped further behind a target that kept moving.
- A single point of dependency. The whole build sat with one developer who left, went quiet, or was quietly reassigned to another client, and no one else on the agency side could pick it up.
- Undocumented architecture. Decisions were made and never written down, so the code became legible only to the person who wrote it, and that person is now unavailable.
- Payment ahead of delivery. Milestones were billed on time elapsed rather than working software, so the money ran out before a shippable build existed.
- Silence instead of bad news. The agency stopped reporting rather than admit it was behind, and the founder learned there was a problem only when the app store submission never happened.
None of these are unusual, and none of them mean the asset is worthless. A half-built app whose agency has gone quiet is still a codebase, a design system, and months of accumulated product decisions. The task is to recover it methodically rather than write it off.
Pro tip: Before you conclude the project is dead, separate two questions that panic tends to merge. Is the agency relationship over? And is the code unusable? The first is often true. The second is usually not, and only an audit can answer it.
What to do in the first week after an agency fails you
The first week is about control and evidence, not code. Work through it in order.
- Secure ownership and access. Confirm the source code repository, the Apple and Google developer accounts, the cloud and database accounts, the domain, and the design files are held in your name or your company's name. If any of these sit inside the agency's accounts, requesting a transfer is the single most urgent action, because access is leverage and losing it is the one failure that is hard to reverse.
- Stop paying for undelivered work. Pause any recurring payment or milestone tied to work that has not shipped. Do this in writing, and keep it factual rather than adversarial, because a cooperative handover is faster and cheaper than a dispute.
- Request a full handover in writing. Ask for the latest source code, a list of third-party services and credentials, the build and release configuration, and any documentation. Put it in an email so there is a record of what was and was not provided.
- Verify your intellectual property terms. Read the contract for the clause that assigns ownership of the code to you on payment. If it exists, the code is yours to take elsewhere. If it does not, resolve that before commissioning new work on top of it.
- Commission a code audit before a rebuild quote. Do not accept a proposal to rebuild from scratch from anyone who has not read the existing code. A rebuild quote issued sight-unseen is a sales position, not an engineering judgement.
That fifth point is where most of the money is won or lost. The instinct after a bad agency experience is to start over with someone new, and a new vendor is often happy to sell exactly that, because a greenfield build is easier to scope than an inherited one. It is also frequently the more expensive and slower path.
Pro tip: Keep the tone with the outgoing agency cooperative for as long as it takes to get a clean repository export and account access. You can be done with the relationship and still need one last handover. Burning the bridge before the export lands can cost you the codebase.
What does a code takeover audit examine first?
An audit is not a vague code review. AppMatic Tech runs a takeover audit across five defined areas and produces a written stabilisation plan as the deliverable, before any feature work is quoted.
| Audit area | What it answers |
|---|---|
| Ownership and access | Do you hold the repository, app store, cloud, domain, and design assets, and is the IP legally yours to continue? |
| Architecture and dependencies | Is the structure sound, are the frameworks current and supported, and are there abandoned or insecure dependencies? |
| Technical debt and dead code | How much of the code is unused, duplicated, or written in a way that makes every future change slower? |
| Integration state | Are the hardware, payment, authentication, and third-party integrations working, half-finished, or broken? |
| Build and release readiness | Can the app be built, signed, and submitted today, or is the release pipeline itself broken? |
The value of doing this first is that it converts an unknown into a fixed scope. A codebase nobody has read can only be priced as an open-ended hourly engagement, which is the same billing model that produced the original failure. Once the audit exists, the remaining work can be quoted fixed-scope and fixed-price, because the surprises have been surfaced on purpose rather than discovered mid-build.
The audit is also where the rescue-versus-rebuild decision is actually made, on evidence rather than instinct.
Rescue or rebuild: how to decide
The decision is not about how the code looks or how familiar it feels. It is about two specific tests: whether the architecture can carry the product roadmap, and whether the cost of changing the existing code has become higher than the cost of replacing it.
| Signal | Points to rescue | Points to rebuild |
|---|---|---|
| Architecture | Structure supports the planned features with reasonable effort | Core architecture cannot support the roadmap without a redesign |
| Code quality | Debt exists but changes are still tractable | Every change is slower than rewriting the affected area |
| Ownership | IP and accounts are yours or recoverable | Code cannot be legally used, or key accounts are unrecoverable |
| Integrations | Third-party and hardware work is partly done and sound | Integrations are fundamentally wrong and would be redone anyway |
| Product state | A meaningful share of the product is genuinely built | Little beyond scaffolding actually works |
In practice, the balance tips toward rescue more often than founders expect, because a rebuild throws away not just the code but every product decision, integration, and edge case the previous team already handled, and those have real value even when the code carrying them is imperfect. A rebuild is the correct answer when the architecture is a dead end or the ownership is unrecoverable, and it is the wrong answer when the real problem was project management, communication, or a single departed developer, since none of those are fixed by discarding working software.
Pro tip: Beware the quote that recommends a full rebuild without an audit. Rebuilding is the easiest thing for a new vendor to scope and the most expensive thing for you to buy. Insist that any rebuild recommendation is justified against the architecture and ownership tests above, in writing.
What a real mid-project takeover looked like
EYVA is a non-invasive wellness device with a companion app that reads six vital signs over Bluetooth Low Energy. The startup's first development engagement, with another vendor, had stalled. The app was partly built, the codebase was inherited and undocumented, and the product needed to reach a shippable MVP on both iOS and Android.
AppMatic Tech took the project over mid-development. The work began with assessing the inherited iOS and Android codebases, documenting the existing architecture, identifying accumulated technical debt and broken BLE integration points, and producing a stabilisation plan. Only then did feature work continue: completing the BLE read and write command integration for the six-vital device, integrating cleanly with EYVA's backend and real-time socket layer, and optimising performance across both native platforms. The engagement ran eight months and delivered a production-ready MVP.
The founder's own account of the outcome is the useful part:
"AppMatic Tech picked up where another team left off and made it work. They stabilised the codebase, completed the BLE integration, and got our app to a point we could actually launch. The eight months we worked together moved faster than the entire prior development period."
That last sentence is the pattern worth noting. A competent takeover of a stabilised codebase routinely moves faster than the stalled engagement that preceded it, because the product decisions are already made and the remaining work is bounded. The full engagement is documented in the EYVA case study.
What does an app project rescue cost?
Rescue engagements at AppMatic Tech are staged so the founder never commits to a large fixed price before the codebase has been read. The audit comes first, and it is what makes the later number reliable.
| Engagement | Scope | Timeline | Investment |
|---|---|---|---|
| Code audit and stabilisation plan | Full five-area audit, written fix list, rescue-versus-rebuild recommendation | 1 to 2 weeks | From $2,500 |
| Stabilise and ship | Recoverable codebase brought to a stable baseline and driven to a release | 6 to 16 weeks | $15,000 to $40,000 |
| Rebuild and complete | New build reusing salvageable product decisions where the audit rules out the existing code | 12 weeks and up | From $40,000 |
Every rescue starts with the fixed-fee audit rather than a full-project quote, because pricing a codebase nobody has read is the same mistake that produced the original overrun. The audit fee is small relative to the build, and it is the step that lets the rest of the engagement be fixed-scope and fixed-price. It is also, occasionally, the step that saves a founder from a rebuild they were about to buy, by showing that the existing code is closer to shippable than it appeared.
For how AppMatic Tech structures engagements in general, see the mobile app development service and the custom software development service.
What AppMatic Tech has shipped in rescues and takeovers
- EYVA wellness app, a mid-project takeover of a stalled engagement, delivering production iOS and Android apps with BLE read and write integration for a six-vital non-invasive measurement device across an eight-month rescue.
- Univia, a mobile product delivered as a mobile app development engagement, shipped to a defined scope and timeline after a clean handover of requirements.
- Trackwel kitchen scale, a Flutter app with a custom BLE integration layer, Laravel API, and React admin panel, taken from zero to MVP in ten weeks with zero app-side BLE errors, an example of the disciplined scoping that prevents the failure this article is about.
For choosing a partner so the next engagement does not stall, see how to hire a software development partner. For the BLE takeover context specifically, see what BLE app development costs and how long it takes.
Contact AppMatic Tech at contact@appmatictech.com to commission a code audit of a stalled build.
Sources
| Claim used in this article | Source |
|---|---|
| Large IT projects run on average 45% over budget and 7% over time while delivering 56% less value than predicted | McKinsey and University of Oxford, delivering large-scale IT projects on time, on budget, and on value |
| Roughly one in three software projects cancelled before delivery | The Standish Group, CHAOS research |
| EYVA takeover scope, timeline, outcome, and client quote | AppMatic Tech delivery data, documented in the EYVA case study |
Frequently Asked Questions
- My app development agency stopped delivering. What should I do first?
- Secure ownership and access before anything else. AppMatic Tech advises founders to confirm they hold the source code repository, the app store and cloud accounts, the domain, and the design files in their own name, then stop paying for undelivered milestones and request a full handover in writing. Only after access is secured is a technical audit of the codebase worth commissioning, because a rescue plan cannot be priced without reading what exists.
- Can a failed or half-built app be rescued, or does it need a full rebuild?
- Most stalled projects are rescued rather than rebuilt. AppMatic Tech took over the EYVA wellness app mid-development from a stalled vendor and delivered a production iOS and Android MVP in eight months by stabilising the inherited codebase rather than restarting. A full rebuild is only the right call when the architecture cannot support the product roadmap or the code quality makes every change slower than a rewrite would be, which a code audit determines in days, not weeks.
- How does a code takeover audit work?
- AppMatic Tech audits an inherited codebase across five areas: repository and account ownership, architecture and dependency health, technical debt and dead code, the state of any hardware or third-party integrations, and build and release readiness. The output is a written stabilisation plan with a prioritised fix list and a decision on rescue versus rebuild, produced before any feature work begins so the engagement can be fixed-scope and fixed-price.
- What does it cost to take over and finish a stalled app?
- AppMatic Tech prices takeovers in three tiers: a fixed-fee code audit and stabilisation plan from $2,500, a stabilise-and-ship engagement from $15,000 to $40,000 for a codebase that is recoverable, and a rebuild-and-complete engagement from $40,000 upward when the audit shows the existing code cannot carry the roadmap. The audit is what makes the later price fixed rather than a guess.
- Who owns my code if my agency disappears?
- Ownership depends on the contract, not on who wrote the code. If the agreement assigns intellectual property to the client on payment, the code is the client's even if the agency is unresponsive, and the client is entitled to a repository export. AppMatic Tech advises founders to verify IP assignment terms and confirm they are named as the owner of the app store, cloud, and domain accounts, because a codebase the client cannot legally use is the one situation where a rebuild becomes unavoidable.