When to Fire Your Software Development Company (And How to Do It Cleanly)

When to Fire Your Software Development Company (And How to Do It Cleanly)

Ending a software development engagement is one of the most stressful decisions a founder or product leader makes. There is always a nagging question: is the problem fixable? Have you communicated clearly enough? Is this company really failing, or are your expectations unreasonable? These questions are worth asking. But they can also become reasons to stay in a failing engagement longer than is warranted, compounding the damage each month.

This guide helps you distinguish between problems that are fixable and engagements that are beyond repair, then walks you through how to exit cleanly if the conclusion is that the engagement needs to end.

The Signs That an Engagement Has Failed Beyond Repair

Not every problem signals failure. The line between a fixable communication problem and a fundamental engagement failure is important to get right. The cost of ending too early is unnecessary disruption and transition cost. The cost of ending too late is continued wasted investment and a product that falls further behind.

Unfixable Communication Breakdown

Communication problems in a development engagement are common. A good vendor will adjust when communication issues are raised directly. The pattern that indicates something unfixable is a communication problem that:

• Has been raised directly, in writing, at least twice
• Showed brief improvement after being raised, then returned to the prior pattern
• Affects multiple people on the vendor side, not just one individual

This pattern suggests the problem is organizational. It will not be solved by another conversation because the organization does not have the capacity or culture to solve it.

Examples of this pattern:

• You receive status updates only when you chase them, despite explicit agreements about reporting frequency
• Questions sent in writing are answered with another question rather than a direct response, consistently across multiple interactions
• Critical issues are raised with you after they have already affected the project timeline, without prior notice

Missed Milestones Three or More Times With No Credible Explanation

Every development project misses milestones occasionally. Requirements change. Technical complexity is underestimated. External dependencies slip. These are normal.

The pattern that warrants concern is:

• Three or more missed milestones on a single project phase
• Explanations that are either absent or cannot be connected to specific causes (team issues are cited vaguely, scope changes are cited without documenting what changed)
• Revised dates that are also missed

By the third missed milestone with inadequate explanation, you are watching a pattern, not a sequence of independent incidents. This company is either not capable of delivering your project or is not prioritizing it adequately.

Code Quality Red Flags From a Third-Party Review

If you have concerns about code quality but lack the technical background to evaluate it yourself, the most useful step you can take is commissioning a third-party code review. Hire a senior developer from a marketplace or a specialist firm for three to four hours to review the codebase.

Red flags that indicate the code is below acceptable quality:

• No unit tests or test coverage below 30% on core functionality
• No documentation on non-obvious functions or system design decisions
• Security vulnerabilities in authentication, data handling, or input validation
• Tightly coupled code that is difficult to modify without breaking unrelated functionality
• Evidence of copy-paste code from tutorials or Stack Overflow answers without adaptation for your context

These problems are not impossible to fix, but fixing them while continuing to build new features is expensive and slow. If the vendor built your product this way, they are unlikely to change their approach on the existing codebase without significant pressure and oversight.

When to Try to Fix vs When to End

The decision framework:

Try to fix if:

• The root cause is clearly identified and specific (one underperforming developer, a miscommunication about scope, a process that was never defined)
• The vendor has demonstrated genuine accountability (acknowledging the problem, not deflecting)
• The relationship has produced good work at other points in the engagement
• You are fewer than halfway through the project timeline

End the engagement if:

• The root cause is organizational culture, not a fixable individual or process issue
• The vendor consistently deflects accountability to your side, external factors, or vague team issues
• The engagement has never produced work you were confident in
• You are more than two-thirds through the project timeline with significantly less than two-thirds of the work complete
• A third-party code review has revealed fundamental quality problems

The hardest situation is when you are somewhere in the middle. In this case, err toward ending sooner rather than later if you are past the halfway point. Every month you continue in a failing engagement is a month of salary paid toward a deliverable you will likely need to partially rebuild anyway.

The Contract Exit Clause and Notice Period

Before you take any action, re-read your contract. Specifically look for:

• Notice period: Most development agreements require 30 to 90 days notice before termination. Honor this in writing.
• Termination for cause vs termination for convenience: Many contracts allow earlier termination if the vendor is in material breach of the agreement (repeated missed milestones, failure to deliver agreed upon scope). If you are terminating for cause, document the specific breaches.
• Work-in-progress payment: What do you owe for work completed but not yet invoiced? Get a clear accounting before the final termination date.
• IP assignment on termination: Ensure your contract specifies that all code, designs, and documentation become your property on termination. If this is not explicit, consult a lawyer before terminating.

Do not communicate the termination verbally before you have confirmed the contract terms. The written notice letter, referencing the specific contract clause and effective termination date, is the official act.

Code Handover Requirements

The code handover is where most acrimonious endings create lasting damage. Be explicit in your termination notice about what you require for handover and by what date.

A complete handover should include:

Source Code

• Full repository access with complete commit history (not just the current state)
• All branches, including any work-in-progress branches
• Transfer of repository ownership to your version control account

Documentation

• Deployment runbook: step-by-step instructions for deploying the application from scratch
• Environment configuration: all environment variables and their purpose (do not include actual secrets in documentation, but document that they exist and where they should be stored)
• Third-party service integrations: list of every external service the application connects to, with account details or instructions for account transfer
• Known issues and technical debt: anything the team knows is broken or suboptimal that you need to be aware of

Deployment Access

• Hosting accounts (AWS, GCP, Azure, Heroku, etc.) transferred to your ownership
• Domain registrar access
• SSL certificate management
• Database access with admin credentials
• CI/CD pipeline configuration

If you do not control these assets, you are dependent on the vendor even after you have paid them off. Insist on full transfer as part of the exit.

Legal and Financial Implications

Payment in Dispute

If there is a payment dispute (you believe they have not delivered what was paid for, they believe you owe for work completed), handle this through the contract's dispute resolution process. Most contracts specify mediation or arbitration before litigation.

Do not withhold payment unilaterally without legal advice. In most jurisdictions, withholding payment for delivered work, even poor work, creates legal exposure regardless of the quality issue.

Intellectual Property

Confirm in writing that all intellectual property developed under the engagement is assigned to you. This is usually in the contract, but it is worth a specific written confirmation as part of the handover process. If there is any ambiguity, consult a lawyer in the vendor's jurisdiction.

Non-Disparagement

If your contract includes a non-disparagement clause (they cannot publicly criticize you, you cannot publicly criticize them), be aware of this before posting about the experience online.

Finding a New Team While Managing the Transition

Start looking for a replacement team before you send the termination notice. This is not bad faith. It is responsible planning. The notice period exists partly so you can make this transition.

Briefing the New Team

When you engage a new development partner, brief them honestly on what happened. Not to damage the previous vendor's reputation, but because:

• The new team needs to understand what state the codebase is in
• The new team needs to understand what organizational patterns caused problems
• Transparency builds trust with your new partner from day one

Specifically, share:

• The third-party code review findings (if you have them)
• The documentation gaps and technical debt you are aware of
• The communication or process failures that contributed to the breakdown

A new team that inherits an undocumented, poorly tested codebase and knows about it in advance will plan their engagement differently than one that discovers the problems after they start.

What to Look for in the New Partner

After a failed engagement, the temptation is to optimize for whatever was missing last time. If the previous vendor had communication problems, you prioritize communication. If they had quality problems, you prioritize code review. This is sensible but incomplete.

The more important question is: what do you need to do differently in your management approach to get a better outcome? Engagement failures are almost always partly a client-side problem. Unclear requirements, insufficient feedback, vague contracts, and no technical oversight on the client side all contribute to bad outcomes.

Our offshore engineering model is designed to include client-side process support as part of the engagement, specifically to prevent the patterns that lead to these situations.

If you are ready to find a more reliable development partner, get a free quote or explore how we work with companies looking for an offshore development team they can actually trust.