Should you fire your development agency?

Replacing a development partner is a decision about the work and responsibilities that remain. Put the delivery evidence, account access and recovery options in writing before deciding whether a reset, specialist support or a change of team is the better next step.

A frustrating month does not establish the cause of a problem. Neither does a reassuring conversation establish that the product is ready. Use the checks below to make the next conversation specific.

First: rough patch or failing engagement?

A missed milestone can reflect a changed requirement, a blocked dependency, an inaccurate estimate or a delivery problem. Ask which explanation applies and what evidence supports it. Look for a pattern across the same agreed scope rather than treating a single miss as a verdict.

A useful recovery discussion includes an explanation you understand, a revised plan with owners and dates, and working evidence of progress since. Compare the next release with that plan. The quality of the explanation and the observed result both matter.

A failing engagement looks like a pattern: sprint commitments missed repeatedly with changing explanations, the estimate-to-finish never shrinking, "done" features that break on contact with real users, updates that arrive late, thin, or only when you chase, and technical questions answered with jargon instead of English. If you want the full checklist, we wrote up the 12 signs your dev team is failing you. They can help identify questions that need evidence. The guide is not a validated failure score.

Before anything else: secure your keys

Confirm what your business controls: the repository, hosting and cloud accounts, domain, app store listings, data and analytics. Review the actual account owners, recovery contacts, agreement and provider restrictions. Ask who can authorize any missing access and which handover dependencies remain. A repository login alone does not establish ownership or the ability to operate the product.

The three options short of firing

Option one: reset the engagement. One direct conversation with three artifacts on the table: a written list of everything between today and launch with estimates, a regular demo of the agreed journey, and a clear process for approving changes. Keep required launch work separate from new ideas. Agree who resolves uncertain requirements and how a change affects the remaining scope and price.

Option two: bring in outside eyes. A scoped review by another qualified team answers the question underneath all the others: is the work actually good? Sometimes the answer vindicates your team and the problem is scope or communication, which is fixable. Sometimes it confirms your gut. Either way you decide from evidence, and you can begin without ending the existing engagement: our Diagnostic is a read-only assessment. It depends on the authorized access and information available; missing access or undocumented behavior stays an explicit limit of the review.

Option three: augment instead of replace. When the team is honest but missing a particular skill, a fractional lead or subsystem specialist may be a better fit than a takeover. Agree the added person's role, authority and review responsibilities with the current team so advice reaches the people doing the work.

When firing is the right call

Reasons to escalate include documented misrepresentation, unresolved access problems, important failures that remain uncorrected, or a structured recovery plan that repeatedly fails against the same agreed requirements. Review the evidence independently where needed, then compare the transition requirements with the risk of continuing. Confirm what your agreement requires before acting.

How to leave safely

1. Establish an authorized access and continuity plan for the repository, cloud, domain, stores and data exports. Record transfer dependencies and the operating owner during the switch.
2. Check your contract for IP assignment, termination notice, and what happens to work in progress. Establish what your actual agreement says rather than assuming a payment or repository login settles the ownership question.
3. Ask for a written handover: how to run the project, what is finished, what is not, known issues. Agree any paid transition work explicitly, including the deliverables, access changes, responsible people and the way you will verify the handover.
4. Keep the explanation accurate and the handover practical. Put the decision, remaining responsibilities and agreed dates in writing. Separate unresolved commercial questions from the steps needed to keep the product operating.
5. Have the next step lined up before the last day, even if the next step is just an audit. Assign someone to monitor failures, provider notices and urgent changes during the gap.

What it means for your budget

A new team may reuse working features, useful design and documented decisions. It also inherits investigation, migration and continuity responsibilities. The value of the existing work has to be established rather than inferred from the amount already spent. Compare the remaining scope and risk of each option rather than assuming a second attempt receives a discount. We explain the comparison in how much it costs to rebuild an app in 2026. The money already spent does not determine which option is now best. Compare the remaining cost, business value, continuity risk and uncertainty. A pause or a smaller release can be a legitimate outcome alongside a repair or takeover.

Still weighing it? Take the 2-minute salvageability quiz to see which band your project is in. Treat it as a conversation prompt, not a technical verdict. You can also book a call and bring the current evidence and options. You will not have to defend past decisions to us.