We are an offshore agency, and we are about to be honest about how offshore agencies waste your money. We have rescued 14 projects from other vendors in the last two years; this list is the pattern we keep seeing. Print it, send it to your next agency on the kickoff call, and watch which items they push back on.
1. They quote in hours, not deliverables
"USD 35 per hour" is not a quote — it is a meter. A real quote names the deliverable, the engineer-days, and the acceptance criteria. We have seen founders pay USD 22,000 for "a checkout flow" with no specified scope and end up with three rounds of rebuilds. Demand fixed-scope per-milestone pricing or a hard weekly cap on T&M.
2. The senior wrote the proposal, the junior writes the code
Classic bait-and-switch. The pitch deck names a Principal Engineer with 12 years of experience. The actual code is written by someone 2 years out of college and reviewed by nobody. Fix: named engineers in the SOW with GitHub handles. Pull their PR history. If the names change post-signing, it triggers a re-pricing.
3. No written change-request process
You ask for "one small change" in Slack. Six weeks later, the bill is 1.6x and nobody knows why. Fix: every change is a written request, with a 24-hour re-estimate before any code is written. No exceptions, even for trivial things.
4. The repo lives on their GitLab forever
Lock-in by repo ownership is the oldest trick in the agency book. Code should live on your GitHub or GitLab from day one, with the agency added as a seat. If a vendor pushes back on this, walk away.
5. No deployment runbook
The site runs, but only one engineer knows how to deploy it. They leave the agency, you are stuck. Fix: a written runbook (README + ops docs) updated weekly, plus at least one of your own people having shipped a deploy by week 6.
6. Test coverage of zero, "we will add tests later"
Tests never get added later. Every refactor is now a regression. Demand a coverage floor in the SOW (we target 60-70% line coverage on business logic) and a CI gate that blocks merges below the floor.
7. Status by vibes, not by metric
"We are 80% done" is not a metric. PRs merged per week, story points closed, p95 latency on the staging deploy — these are metrics. A vibes-based status report is how you discover a one-week miss is actually a six-week miss.
8. They sell you the framework, not the outcome
If the proposal opens with "we use Microsoft technologies" or "we are React experts", the agency is selling supply, not outcomes. A good agency's proposal opens with your user's problem and what success looks like in 90 days. The framework is a footnote.
9. No design system, every screen reinvents the wheel
You ship 40 screens and 40 button variants. Maintainability collapses inside a quarter. Fix: design system day one — even if it is just a fork of shadcn/ui or MUI with your brand tokens. We ship every project on a tokenised component library because rebuilding buttons is the most expensive cheap mistake.
10. They batch communication
You ask a question on Monday, get an answer Friday. By Friday the question is stale and the bug is live. Fix: a daily decision window (15 minutes, same time, video on) and a Slack #decisions channel with a 48-hour default-answer rule for anything that does not get a response.
11. No observability after launch
The app ships, the agency disappears, and three weeks later you discover via a user email that error rates have been at 8% the whole time. Fix: Sentry (or equivalent) wired before the first deploy, error budget alerts in your Slack, and at least one ongoing engineering hour per week dedicated to triage.
12. They will not tell you what they cut
A good agency tells you what they are not shipping in the MVP and gives you a written list. A bad agency lets you discover at launch that the admin panel does not exist. Fix: an explicit "out of scope" section in every SOW, longer than the "in scope" section if it has to be.
What does a healthy engagement actually look like?
| Healthy | Toxic |
|---|---|
| Fixed-scope quote with per-milestone billing | Hourly billing with no cap |
| Named engineers in SOW with GitHub handles | Generic "team of 5 seniors" |
| Repo on your org, agency added as seats | Code on agency's GitLab |
| Written change requests with 24h re-estimate | Verbal "yeah we can do that" |
| Daily decision window, async demos twice weekly | Status reports every Friday |
| Coverage floor and CI gates from week 1 | "We will add tests at the end" |
| Explicit out-of-scope list | Optimistic in-scope list |
| Runbook + at least one of your people shipping deploys | One agency engineer holds all keys |
| Observability wired before launch | "It works on staging" |
| Honest "no" on bad-fit projects | "Yes" to everything during sales |
How do we keep ourselves honest?
Every clause above is in our standard SOW. We publish our process on our about page, we name engineers in every quote, and we have walked away from at least four projects in the last 18 months that did not fit. We would rather lose a deal than ship the kind of project this list describes.
What questions should you ask on the first call?
Use these five on your next sales call. The answers separate serious agencies from the rest:
- "Will the engineers named in this proposal be the ones who write the code? Can you put their GitHub handles in the SOW?" — Watch the hesitation.
- "If we ask for a change mid-project, how does the change-request and re-pricing process work? Can you send me your template?" — A good agency has a one-pager. A bad agency has a shrug.
- "What is your test-coverage floor, and what is your CI policy on merging below it?" — Anyone who answers "we test thoroughly" without specifics is winging it.
- "What is the most recent project you walked away from, and why?" — Agencies that have never said no will say yes to your worst ideas.
- "Can I speak to a client whose project did not go well?" — Every agency has these. The honest ones will give you a name.
What rescue projects look like
When we take over a struggling project from another vendor, the first two weeks always follow the same pattern: code audit (architecture, security, debt), test-coverage assessment, dependency vulnerability scan, and a written 30-day stabilisation plan with explicit decisions on what we keep vs rewrite. We bill for this two-week phase whether you continue with us or not, because the report is useful even if you go elsewhere. Roughly two-thirds of our rescue engagements convert to a full retainer; the other third take the report and either hire in-house or pick a different agency. Both outcomes are fine by us.
Got a project that smells like this list?
If you are in the middle of a project that ticks half these boxes, we run rescue engagements — code audit, debt assessment, and a 30-day stabilisation plan. Send us a brief on our quote page. Curious about a fresh start? See our pricing and process in our SaaS MVP cost piece.