Signs your software vendor isn't going to deliver

Your vendor missed another milestone, and the explanation sounded reasonable at first. But after two more weeks and yet another delay, it is clear this is not just a hiccup. It is a pattern. The hard part is knowing when you’ve crossed the line from acceptable delays to structural issues that won’t resolve themselves.

Every software project encounters problems, and timelines do shift. That doesn’t automatically mean the vendor can’t deliver. But certain patterns indicate deeper problems, and no amount of patience will fix them.

When communication stops being communication

A vendor who responds to every question within 48 hours but never provides useful information has a communication problem disguised as responsiveness. The response time is fine, but the substance is missing. For example, you ask, “When will the payment integration work?” and get back, “We’re prioritizing that this sprint.” That’s not an answer.

In projects we’ve managed, the first warning sign is usually vague progress updates that sound detailed but don’t contain demonstrable work. If a vendor says, “We’re 90% done with the user dashboard” for three weeks straight, the last 10% is actually 60%, and they don’t want to admit it. When you ask to see the dashboard, you should be looking at a working interface with real data, even if half the buttons don’t work yet. If you’re looking at screenshots or a slide deck, the work isn’t 90% done.

The second pattern is losing direct access to the people writing code. Early in a project, you talk to developers, and questions get answered with technical specificity. But gradually, every question routes through a project manager. The PM is helpful and professional, but they don’t know why the API is returning errors or how long it will take to fix. They’re a buffer, and buffers exist because someone doesn’t want you seeing what’s actually happening.

A logistics company we worked with spent four months in this pattern. Their vendor’s PM was excellent at scheduling meetings and sending status reports, but the developers never joined calls. When the company finally insisted on a technical walkthrough, the database schema didn’t match the requirements doc. The vendor had been building the wrong data model for three months.

What missed deadlines actually mean

One missed deadline is normal. Two in a row means something unexpected happened. Three consecutive missed milestones with different explanations each time means the vendor doesn’t actually know when the work will be complete, and they’re guessing.

The concerning pattern isn’t missing dates. It’s missing dates without acknowledging the pattern. A vendor who says “we’ve missed three milestones and the problem is X, here’s what we’re changing” is being honest. A vendor who treats each delay as an isolated incident either doesn’t see the pattern or doesn’t want to discuss it.

After three months on a project, you should be able to open a browser and test something. It doesn’t need to be feature-complete, but it needs to exist as a working piece of software you can interact with. If you’re still looking at wireframes or staging environments that aren’t ready for you to access, the project is behind in ways the timeline doesn’t reflect.

We’ve inherited multiple projects where the original vendor spent six months “building the foundation” with nothing to show. In every case, the foundation was either over-engineered to the point of being unusable or didn’t exist at all. Real foundation work produces working infrastructure you can deploy test code to. If they can’t show you that, they’re not building a foundation.

When you start seeing different developers every month

In the first three months of a project, you should be talking to the same two or three developers every week. You learn their names, they learn your process, and knowledge accumulates. When you start seeing different faces every sprint, something changed.

High turnover costs projects in ways that don’t show up on timelines. The new developer doesn’t know why the data model was structured that way. Features that should take three days take eight because someone needs to reverse-engineer undocumented decisions.

A healthcare company we worked with had this exact problem. Their vendor rotated through five developers over nine months. Each spent two weeks figuring out what the previous developer built. When we assessed the project, the codebase had three different architectural patterns because three developers had each started their own approach without finishing it.

The question isn’t whether the vendor has turnover. Every company does. The question is whether they have a handoff process that preserves institutional knowledge. If the new developer doesn’t know why decisions were made, the project is losing information faster than it’s gaining features.

What technical debt looks like before you see the code

You probably don’t review your vendor’s code directly, but you can see technical debt accumulating in how the application behaves.

New features start introducing bugs in existing features. The vendor describes these as “edge cases” or “unexpected interactions.” What they actually mean is the codebase doesn’t have a coherent structure anymore. Features are being bolted on instead of integrated, and every addition destabilizes something else.

Deployments start requiring rollbacks. The vendor pushes an update on Friday afternoon, and by Monday morning, they’re apologizing and reverting to the previous version. This happens once, then twice, then it becomes the expected pattern. At that point, the problem isn’t the deployment process. The problem is they’re not testing before they deploy because the codebase has become too complex to test properly.

Performance degrades over time. The application was fast in month two, but by month six, pages take longer to load. The vendor explains this as “data volume” or “scaling challenges,” but the data volume didn’t increase 10x. The code got messier, and every operation now does more work than needed.

A financial services company we worked with experienced all three patterns. Their vendor delivered new features every sprint, but each release broke something. After eight months, the application was slower than the spreadsheet it replaced. We spent the first month stabilizing what existed before building anything new. The codebase had no tests, no consistent naming conventions, and database queries that ran on every page load unnecessarily.

When scope disputes become the primary conversation

Requirements clarify during a project. That’s expected. The vendor should be asking clarifying questions and proposing refinements. What’s not normal is when every conversation becomes a negotiation about whether something is in scope.

For example, you ask for a report to show data by region. The vendor responds that regions weren’t mentioned in the original requirements, so this is a change order. You point out that the requirements specified “flexible filtering.” They agree that’s true but argue that building region as a dimension wasn’t explicitly scoped. The conversation isn’t about what you need anymore. It’s about contract interpretation.

This pattern emerges when a vendor underbid the project and is trying to minimize work to stay profitable. Every feature becomes a question of whether it’s technically required to meet the letter of the contract. The relationship stops being a collaboration and becomes adversarial.

The comparison point here is fixed price versus hourly structures. A fixed price contract creates an incentive to minimize scope, while an hourly contract creates an incentive to maximize hours. Neither structure prevents the problem. What prevents it is a vendor who bid accurately and isn’t trying to make up for underestimating. If scope disputes are consuming more time than feature discussions, the commercial relationship is broken regardless of contract type. A vendor that treats each change as a negotiation isn’t practicing custom software development. They’re managing scope.

The math that tells you when to cut losses

Switching vendors mid-project costs something, but staying with a failing vendor costs more, even if the cost is less visible because it accumulates slowly. The break-even calculation is straightforward.

Take your current monthly burn rate and multiply by six months. That’s your cost to continue. Add the opportunity cost of delayed launch, which for most projects is at least equal to the direct costs. That’s your comparison number.

On the other side, calculate termination fees plus two months of knowledge transfer and new vendor onboarding plus four months at the new vendor’s rate. If that number is less than your cost to continue, switching is cheaper even if it feels more expensive.

A retail company we worked with was spending $35k per month with a vendor who had missed six consecutive milestones. At month 14, they had 40% functionality. They were hesitant to switch after spending $490k.

At their current rate, the vendor needed another eight months. That’s $280k plus eight months of manual processes costing $15k per month in staff time.

Switching meant a $30k termination fee, two months to document and transition, and four months to rebuild at $40k per month. Total cost was $210k plus six months to completion. They saved $70k and delivered four months earlier.

What it looks like when a vendor is struggling financially

Vendors don’t usually tell you when they’re having cash flow problems, but the signs appear in how they handle billing. A vendor who starts asking for early payment or restructured payment terms is managing a cash problem. That might resolve itself, or it might mean they’re using your project payments to cover payroll on other projects.

Aggressive change order pricing is another signal. Every small adjustment becomes a negotiation about additional fees because the vendor needs the revenue. A financially stable vendor has flexibility to handle minor scope adjustments without treating each one as billable.

The most direct signal is when key staff leave. If the lead developer departs mid-project without a replacement plan and knowledge transfer, you’re about to lose months of institutional knowledge. In a stable company, transitions are managed. In a struggling company, they destabilize projects.

None of these signals mean you should immediately terminate, but they do mean you should ask direct questions about financial stability and succession planning. A vendor who answers honestly and has a plan is manageable. A vendor who deflects is a risk you might not want to carry.

What recovery looks like when it’s actually possible

Not every troubled project should be terminated. Some can be recovered with clear corrective action and aggressive oversight. The question is whether the vendor acknowledges the pattern and proposes structural changes, not just timeline adjustments.

Recovery requires three things. The vendor needs to identify the root cause of repeated delays without blaming external factors they can’t control. They need to propose process changes, not just promise to work harder. And they need to agree to weekly demos of working software, not status reports.

A manufacturing company we advised had a vendor who missed four milestones in a row. Before terminating, they sent a formal letter requiring a recovery plan within one week. The vendor responded with a detailed technical assessment identifying database performance as the core issue, proposed a two-week remediation sprint, and committed to bi-weekly demos with working features.

The vendor delivered. They fixed the bottleneck, hit the next three milestones, and completed the project two months late but fully functional. Recovery worked because the vendor was honest about what went wrong and willing to change.

If your vendor responds to concerns with defensiveness, revised timelines without process changes, or promises to “work harder,” recovery isn’t likely. The pattern will repeat because the underlying cause hasn’t been addressed.

When the decision becomes obvious

There’s a point in every failing vendor relationship where the evidence accumulates past ambiguity. You’re not wondering if there’s a problem anymore. You’re wondering if you’ve waited too long to act.

That point is usually when you realize you’re spending more time managing the vendor than they’re spending delivering working software. If your weekly vendor meeting is primarily you asking for updates and them explaining delays, the relationship has inverted. You’re doing project management work they should be doing.

The second indicator is when you stop believing their timelines. They say two weeks, and you mentally add a month. When that becomes your default assumption, trust is gone. Projects don’t recover without trust.

If your project matches these patterns closely enough, the diagnostic worth doing is a technical review with someone who has no relationship to either you or the vendor. Have them review the codebase, the architecture documentation, and the deployment process. That review will tell you whether you’re looking at recoverable delays or structural failure. If you want to compare notes on what makes a project recoverable versus unsalvageable, or you’re ready to start fresh with a partner you can trust, let’s talk about building custom software.