Should you fire your development agency?

Whether to replace a development partner depends on the work and the responsibilities that are left. Write down the delivery evidence, the account access and the recovery options before you decide whether a reset, specialist support or a change of team is the better next step.

One frustrating month does not tell you what is causing a problem, and one reassuring conversation does not tell you the product is ready. Use the checks below to make your next conversation with the team specific.

First: rough patch or failing engagement?

A missed milestone can come from a changed requirement, a blocked dependency, a wrong estimate or a delivery problem. Ask which one it was and what evidence supports that. One miss is not a verdict. Look for a pattern of misses against the same agreed scope.

A useful recovery conversation gives you an explanation you understand, a revised plan with owners and dates, and working evidence of progress since then. Compare the next release with that plan. Judge both how good the explanation was and what you saw delivered.

A failing engagement looks like a pattern: sprint commitments missed repeatedly with changing explanations, the estimate-to-finish never shrinking, "done" features that break when real users touch them, 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 you find the 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. Look at who the account owners and recovery contacts really are, and at your agreement and each provider’s restrictions. Ask who can authorize any access you are missing and what the handover still depends on. A repository login alone does not mean you own the product or can operate it.

The three options short of firing

Option one: reset the engagement. Have one direct conversation and ask for three things: 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 the work required for launch separate from new ideas. Agree who settles unclear 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 behind most of the others: is the work good? Sometimes the answer is that your team is doing fine and the problem is scope or communication, which you can fix. Sometimes it confirms what you suspected. In both cases 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. Where access is missing or behavior is undocumented, the review states that as a limit.

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

When firing is the right call

Reasons to escalate include documented misrepresentation, access problems that stay unresolved, important failures that nobody corrects, or a structured recovery plan that keeps failing against the same agreed requirements. Get the evidence reviewed independently where you need to, then weigh what a transition would take against the risk of continuing. Check what your agreement requires before you act.

How to leave safely

1. Make a plan for authorized access and continuity that covers the repository, cloud, domain, stores and data exports. Write down what each transfer depends on and who operates the product during the switch.
2. Check your contract for IP assignment, termination notice, and what happens to work in progress. Read what your agreement says. Having paid, or having a repository login, does not settle the ownership question.
3. Ask for a written handover: how to run the project, what is finished, what is not, known issues. If you pay for transition work, agree it explicitly: the deliverables, the access changes, who is responsible and how you will verify the handover.
4. Give the team an accurate explanation and keep the handover practical. Put the decision, the remaining responsibilities and the agreed dates in writing. Keep any open commercial questions apart from the steps needed to keep the product running.
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 takes on the investigation, the migration and the job of keeping the product running. What you have spent does not tell you what the existing work is worth, so have it checked. Compare the remaining scope and risk of each option, and do not assume a second attempt comes at a discount. We explain the comparison in how much it costs to rebuild an app in 2026. The money already spent does not decide which option is best now. Compare the remaining cost, business value, continuity risk and uncertainty. A pause or a smaller release can be a reasonable outcome, as can a repair or a 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 free consultation and bring the evidence and options you have so far. You will not have to defend past decisions to us.