Why 67% of Offshore MVP Projects Require Significant Rework

We've inherited a steady stream of offshore-built MVPs on rescue engagements. The pattern is consistent enough to have a shape. Engineers in India or Ukraine or the Philippines who can code fine, wrapped in a governance structure that guarantees the work falls apart by month four. Gartner puts the offshore rework rate at 67%. Deloitte found 59% of companies dissatisfied with offshore development outcomes. Those numbers don't come from mediocre engineers in other countries. They come from a governance problem that travels across every geography.

The question "should I outsource my MVP?" has the wrong frame. The real question is "what governance makes outsourcing work?" When the answer is "none," the 67% is what happens next.

The failure patterns that produce the 67% figure are surprisingly specific, and the structural markers that separate the 33% that works from the 67% that doesn't are testable in advance.

Where the 67% Figure Actually Comes From

The headline number is widely cited but worth unpacking. It refers to Gartner research referenced in seanconnolly.dev's rescue engineering writeup, describing offshore software projects — not MVPs specifically — that require "significant rework." The definition of rework is fuzzy: it includes full rewrites, partial refactors, and hardening passes. Not all of the 67% is a disaster; some of it is a 20% fix on an otherwise-working codebase.

The related Deloitte study, cited in the same source, found 59% of companies dissatisfied with offshore outcomes — a softer measure, measuring business-outcome dissatisfaction rather than technical rework. Take both numbers as directional: roughly half to two-thirds of offshore projects fail to deliver without follow-up engineering.

The more interesting question is why the other third works. That's where the structural pattern lives.

Six Failure Patterns That Produce the 67%

1. Multi-layer subcontracting. You hire an agency in one country. They subcontract to a second country. That team subcontracts individual developers through a staffing platform. By the time your code is being written, it's three relationships away from your contract. Nobody in the chain has a complete view, and the engineer typing the actual code has no incentive to care about your outcome. This is the single most predictive signal of post-launch rework.

2. Fixed-price contracts with vague scope. The contract says "build an MVP for $45,000." The scope document is two pages of bullet points. The first ambiguity becomes a negotiation, the second becomes an argument, the third becomes a change order. By month two, the agency is losing money on the engagement and their fastest path to profitability is cutting corners on work you can't easily verify — test coverage, observability, error handling, the production engineering layer we've covered across this series.

3. No named engineering lead. The sales call was with a polished salesperson. The build is staffed by whoever's on the bench. You don't know who's writing your code, you can't reach them on Slack, and code review happens (if at all) by a rotating cast that changes weekly.

4. Time zone as the only contact point. Async-first communication works. "We'll talk during our overlap hour" doesn't. Teams that operate across 10+ hour time differences need written communication rigor that most offshore shops don't have — decisions are documented, questions are answered within 24 hours, and the founder doesn't need to be awake at 3 AM to unblock the week's work. Without that rigor, progress slows to the rate of synchronous conversation, which is never enough.

5. No shared access to production. The offshore team has deploy access. You don't. When the build ends, the only way to change anything is to go back through them. We covered this in post-launch engineering — it's the Month 1 finding that surprises founders the most, because it's invisible during the build.

6. Cultural mismatch on "done." "Done" means "happy path works." In production engineering, "done" means "works, tested, monitored, won't page someone at 3 AM." That gap is where the 67% lives. Neither side realizes they're talking about different things until handoff.

The Structural Markers That Predict the 33%

Not every offshore engagement ends in rework. The ones that don't share a specific profile — we've inherited enough of both outcomes to spot the difference on the first call. The predictive markers:

Direct employment, not subcontracting. The engineers writing your code are W-2 employees (or the local equivalent) of the agency you contracted with. No staffing platforms, no third-party labor pools, no "we partner with a team in X." If the contract chain is one link, you have a chance of accountability. Two links and the chain is too long.

Fixed team for the full engagement. Same engineers on your project from week 1 to week 14. You know their names, their LinkedIn profiles, their timezone. They stay through the handoff. If the agency rotates engineers mid-project, the institutional knowledge walks out the door and never comes back.

Written code review policy. Every merge goes through at least one review by a named senior engineer. The policy is documented; the CODEOWNERS file in the repo reflects it; the review comments in GitHub show it actually happens. This is the single strongest correlation with production-engineering quality.

Shared deploy environment. Your staging and production AWS accounts (or GCP, Azure). Your credentials. The agency has a scoped IAM role they can revoke on day one. They don't own the infrastructure; they operate in yours.

Time-and-materials or milestone-based contract. Not fixed price. T&M aligns the agency's economic incentive with yours — the agency gets paid for the work, not punished for doing the work well. Milestone-based works when the milestones are small and concrete enough to verify. Fixed price at anything larger than a 2-week sprint is almost always the wrong contract shape.

English-speaking engineering lead on weekly calls. Not a project manager translating on behalf of the engineering team. The engineer writing architectural decisions is on the call, in English, answering questions. Chemistry lives here — if the lead engineer is hesitant to commit to architectural positions, the codebase will reflect that hesitation.

An offshore engagement that hits all six markers is statistically more likely to land in the 33% that doesn't need rework. An engagement that misses three or more is almost certainly in the 67%.

What "Rework" Actually Costs

The rework number is abstract. The cost is concrete. An MVP built for $45K that requires "significant rework" typically needs:

• 4–8 weeks of cleanup engineering at $100K–$150K (per vibe coding rescue ranges)
• OR a 3–6 month rebuild at $80K–$150K plus the opportunity cost of the stalled product
• OR a new team entirely, hired from scratch, at $140K–$240K/year per engineer fully loaded

The founder who spent $45K to save on the original build has now spent $145K–$390K total to reach the same outcome a $90K mid-market US engagement would have produced in the first place. This is the pattern seanconnolly.dev's writeup describes as the vibe coding cleanup wave — but the failure mode is identical whether the MVP was AI-generated or offshore-built.

The Honest Offshore Answer

Offshore isn't the problem. Offshore without structure is. There are excellent engineering teams in Eastern Europe, Latin America, and South Asia that ship at US-level quality for half the cost. We've partnered with several. There are also broken shops in the same regions that produce the 67% rework rate.

What separates the two isn't the country. It's whether the six structural markers above are present. If the agency offers direct employment, a fixed team, a written code review policy, shared deploy access, a T&M contract, and an English-speaking engineering lead, you're evaluating a team that can produce US-quality work at 40-60% of the US cost. If any of those six is missing, you're buying a probability distribution that skews toward the 67%.

The founder's job is to evaluate for the markers, not the cost. Cost-first evaluation is what produces the rework rate. Marker-first evaluation is what puts you in the third that works.

The Compressed Version

Offshore doesn't fail. Ungoverned offshore fails. The 67% is what that looks like at scale.

Frequently Asked Questions

Is offshore MVP development cheaper than domestic?

On sticker price, yes — Eastern European rates run $40–$80/hour versus $120–$200/hour in the US (Raftlabs 2026 data). On total cost of ownership, only when the offshore team hits the structural markers (direct employment, fixed team, code review policy, shared deploy access, T&M contract, English-speaking engineering lead). Without those, the rework multiplier (1.67x per Gartner) pushes the total cost past the US equivalent.

What's the difference between offshore and nearshore development?

Offshore typically means a 10+ hour time zone difference (US → India, Philippines); nearshore means a 0–4 hour difference (US → Latin America, Canada → Mexico; Western Europe → Eastern Europe). Nearshore has material advantages in synchronous communication and overlapping business hours, which reduces the async-rigor requirement. Same structural markers apply to both — the geography matters less than the governance.

Why does Gartner say 67% of offshore projects need rework?

The 67% figure, cited across industry sources from seanconnolly.dev, reflects a definition of "significant rework" that includes full rewrites, partial refactors, and hardening passes. The root cause across the cases isn't engineering skill — it's governance failures: multi-layer subcontracting, fixed-price contracts with vague scope, no named engineering lead, and cultural mismatches on the definition of "done."

How do I evaluate an offshore MVP agency?

Six markers to check: 1) Engineers are direct employees, not subcontracted. 2) Fixed team for the full engagement, with LinkedIn profiles you can verify. 3) Written code review policy in the CODEOWNERS file. 4) Deploy access is in your cloud account, not theirs. 5) Contract is time-and-materials or small-milestone, not fixed-price-for-unclear-scope. 6) Weekly calls include the English-speaking engineering lead, not just a project manager. Engagements missing three or more of these markers are statistically likely to require rework.

Is it better to hire an offshore team directly or go through a US agency with an offshore team?

Directly is cheaper on paper but requires the founder to handle the governance themselves (interviewing, code review process, contract structure, time zone management). A US agency with a named offshore team adds a governance layer at 20-40% cost markup — worth it for non-technical founders who can't operate the governance alone, not worth it for technical founders who can. The middle option — a mid-market US-led agency with known offshore partners — is often the right balance for founders in the first-MVP stage.

Need help? Talk to an engineer.