Something feels off. Your vendor's updates have gotten vague. Deadlines keep slipping. Or the feature list keeps growing in ways you didn't plan for. You're not sure whether to push harder, wait it out, or pull the plug — and every week you wait, the situation gets harder to unwind.
This is one of the most common situations founders find themselves in mid-project. The instinct is usually to give the vendor more time. But there's a real difference between early intervention and late intervention. This guide walks through what to do, by situation, when an outsourced development project starts going wrong.
Recognizing the Warning Signs
Most project failures don't happen suddenly. In hindsight, the signals were there — but they got explained away or ignored.
Signs related to timeline
- "Almost done" or "by end of week" has been the answer for two weeks running
- Milestone dates shifted without a clear explanation of why
- Requests to see partial work are met with "we'll share when it's cleaner"
Signs related to communication
- Response times are gradually getting longer — hours become days, days become a week
- Questions get answered with "we'll check on that" instead of actual answers
- Progress updates consist of a single line saying everything is on track
Signs related to deliverables
- If you have access to the dev environment, what you see doesn't match what you've been told
- Demos or testable builds keep getting pushed back
- When you push back on something, responsibility gets redirected toward your requirements
One warning sign in isolation doesn't mean crisis. But when two or three appear at the same time, it's time to have a direct conversation — not next week, now.
When Timelines Are Slipping
Delays are common in software development. The question isn't whether a delay happened, it's why — and whether the response to it is being handled honestly.
Start by understanding the cause.
Some delays come from legitimate sources: the technical complexity was underestimated, a key team member changed, or a requirement turned out to be more ambiguous than expected. These are workable. Other delays come from the vendor taking on too many projects at once, or from simply not making progress. Those need a different response.
What to do
-
Ask for specifics, not summaries. Instead of "how's it going," ask: "Can you share what's been completed this week, what's in progress, and what's blocked?" This forces a concrete answer.
-
Get the revised timeline in writing. A verbal "we'll have it by next Friday" isn't enough. Confirm over email with the specific features and dates spelled out.
-
Add a mid-point check-in. If you've reset to a new deadline, add a checkpoint halfway there. Two weeks from now, schedule a quick call to verify progress — don't wait for the due date to find out things are still behind.
-
Reference the contract. If there are delay clauses or penalties, this is the time to bring them up — not as a threat, but as a shared frame of reference. "Let's look at how the contract handles this situation" is a reasonable thing to say.
If the delays are repeated and the explanations don't hold up, read the next two sections.
When Feature Requests Keep Expanding
It's natural to think of new features as development gets underway. Seeing the product take shape surfaces ideas. The problem is when those additions happen informally, without tracking their impact on timeline or budget.
From the vendor's side, this is also uncomfortable. Saying no risks the relationship. Saying yes without adjusting the contract means absorbing the cost. So the additions pile up quietly — until they explode at the end.
Immediate steps
- Get a written list of what's been completed and what's in active development, against the original contract scope.
- For each informal addition you've requested, ask the vendor to estimate the time and cost impact.
- Separate the list into "must be in this version" and "can go in the next version." Protect the core delivery.
If this pattern has been recurring throughout the project, it's worth understanding the mechanics of why small additions compound so quickly. We've covered that in depth in The Real Cost of "Just One More Feature".
When Communication Has Broken Down
No updates, slow replies, meetings that keep getting rescheduled — this is communication breakdown. Left alone, you're likely to receive a final product that doesn't match what you asked for, because no one caught the drift along the way.
How to reset the communication structure
First, consolidate to a single channel. When conversations are split across email, Slack, text, and calls, things fall through the gaps. Agree on one place, then lock in a weekly check-in — 15 minutes is enough. Structure it as: what was completed this week, what's scheduled for next week, and any blockers.
If progress is hard to verify from conversation alone, ask the vendor to share the dev environment access, or to send a short screen recording walking through what's been built. A real demo is worth ten status updates.
If the breakdown stems from an agreement that was too open-ended from the start — where the vendor was told to "just handle it" — that structural problem compounds everything else.
For a closer look at what transparent project communication actually looks like, see Outsourcing Transparency and Client Portals.
When the Vendor Itself Seems Unstable
Sometimes the problem isn't the project — it's the company running it. Staff turnover, missed payments to their own contractors, sudden silence — these can signal that the vendor is in operational trouble.
Warning signs
- Your point of contact has changed, or you found out a key person left after the fact
- The team working on your project is different from who you were introduced to
- The vendor's social media, website, or public-facing activity has gone quiet
- Calls go unanswered and emails take multiple days to receive any response
What to secure immediately
If you're concerned about vendor stability, prioritize these:
-
Source code access. Your code should be in a repository (GitHub, GitLab, or similar) that you have direct access to. If the vendor controls it exclusively, you have no recourse if they disappear. If this access isn't in your contract, request it now.
-
Server and infrastructure credentials. The server, domain, and related accounts should be registered or accessible to you. If everything is under the vendor's accounts, you could lose access to your own product overnight.
-
Intermediate documentation. Wireframes, API specs, database schemas, and design files produced along the way should be shared with you regularly — not handed over only at the end. If another team has to take over, they need this to continue.
Verifying these ownership rights should happen before a project starts, but it's never too late to request them mid-project. If you're also revisiting the original contract, the outsourcing quote review guide covers what to look for in the terms.
Keeping It From Becoming a Dispute
Most outsourcing conflicts trace back to a gap between what was requested and what was actually delivered. Left unaddressed, that gap costs both sides. Establishing the facts objectively, before the conversation turns adversarial, is the fastest route to a resolution.
Start by putting scope and deliverables side by side
Lay the contracted scope against what you have actually received, in a single table. Include any changes agreed to along the way. In most cases, building that table is enough to show precisely where things diverged — and renegotiating that one point resolves the rest.
Most of this gets settled at the negotiating table
Separate completed work from outstanding work, then propose which remedy is realistic for what remains: a revised timeline, a reduced scope, or additional work to close the gap. Whoever puts a workable option on the table first tends to lead the negotiation. Keep the discussion in email, and confirm verbal agreements in writing, however briefly. That is what prevents the same conversation from repeating.
When the call is hard to make, bring in a third party
Whether the current deliverables satisfy the contractual requirements is difficult for a client to judge alone. In that situation, having an independent development expert review the code and deliverables is the most reliable option. An objective assessment gives both sides a clear basis for deciding what happens next.
The best time to prevent disputes is before the contract is signed. Understanding the full picture of outsourcing before you commit is the most effective risk mitigation. The Complete Guide to MVP Outsourcing for Startups covers what to evaluate before you start.
If your current project is causing concern and you're not sure what step to take next — a 30-minute consultation can help you assess where things stand and what your options are.