A quote arrives at $60,000 for a year of development capacity. Another arrives at $180,000. The first one is not three times cheaper, and the second one is not three times better. Both numbers are incomplete in the same way: they price the work the vendor does and omit the work you will do to make that work usable. This page is an attempt to enumerate the omitted part so it can be compared honestly.
Our interest here is obvious, so treat the list as a checklist to apply to every vendor including us. Several of these costs apply to any external team regardless of where it sits. The ones that are genuinely structural to distance are called out as such.
Specification effort
Work priced against a document is bounded by that document. Someone has to write it, and writing a specification that a team unfamiliar with your business can implement correctly is not clerical work. It requires knowing what happens when a job is closed twice, which system wins when two records disagree, and what the finance team does on the last day of the month that nobody has documented.
That person is usually your most constrained employee: an operations lead, a controller, or the one engineer who understands the legacy system. The hours they spend writing and clarifying requirements are real cost, and they are drawn from the same people whose day jobs are running the business. Budget them explicitly or they will be paid out of something else, usually the quality of the thing they were supposed to be doing instead.
Decision latency
This is the cost most specific to distance and the one most consistently underestimated. In operational software, a developer hits a question the specification does not answer several times a week. Not a large question, usually. Whether a canceled load still bills. Whether a partial refund reopens the job. Which address wins when the CRM and the ERP disagree.
When the team shares your working day, that question costs an hour and a short conversation. When it does not, the developer has three options: wait a full cycle, guess, or build something configurable enough to accommodate both answers. Waiting is the honest option and it is the one that shows up in the schedule. Guessing is the cheap option and it shows up months later as rework. Building for both is the expert option and it shows up permanently, as complexity in a system that now has a setting nobody remembers the reason for.
Rework and the cost of passing acceptance
The most expensive defect is not the one that fails testing. It is the one that satisfies the ticket precisely, passes acceptance, reaches production, and turns out to encode a misunderstanding of the business. Nobody catches it, because it does exactly what the specification said.
You pay for that three times. Once for the original build. Once for the rebuild after someone in operations notices the numbers are wrong. And once for the period in between, when people were making decisions from a report that did not mean what they thought it meant, or working around the system in a spreadsheet that is now itself load-bearing.
- A commission calculation that is correct per the document and wrong per the actual agreements, discovered at quarter end
- An integration that silently drops records failing a validation nobody knew existed, found during an audit
- A permissions model built for one location, deployed to eleven, where every branch manager can now see every branch
- A report that counts completed jobs in UTC for a business that closes its day at 6pm Eastern
The coordination layer
Larger teams require management, and you are paying for it whether or not it appears as a line item. An account manager, a business analyst, and a delivery lead sitting between you and the people writing code are usually funded from inside the blended rate, which is part of why the rate is lower than it looks and the throughput is lower than the headcount suggests.
This layer is not useless. It exists because a team of twelve genuinely cannot be coordinated by the client directly. But it does mean that the description of your business travels through two or three people before it reaches the person implementing it, and every hop is a chance for a rule to lose its exception.
Turnover and context loss
Staffing changes are normal in any delivery model, and the cost is proportional to how much undocumented context the departing person held. On a well-documented, well-specified codebase it is a modest handover. On operational software where a great deal of business knowledge was acquired verbally over months, it is a partial restart that you fund.
The practical defense is the same regardless of vendor: insist that domain rules end up in the repository as tests and written decisions rather than in a person. Ask any vendor how they capture a business rule discovered in conversation. The answer tells you what a departure will cost you.
Putting a number on it
None of this is useful as a general warning. It is useful as arithmetic. Take the quote, then add the costs that land on you, using conservative estimates and your own loaded hourly figures.
| Cost | Larger team at a low rate | Small senior team, fixed increment |
|---|---|---|
| Vendor invoice | $60,000 | $95,000 |
| Specification written by your staff | 120 hours | 25 hours |
| Questions, reviews, and clarification | 150 hours | 45 hours |
| Acceptance testing by your team | 80 hours | 40 hours |
| Internal cost at $85/hr loaded | $29,750 | $9,350 |
| Rework after acceptance | One cycle, commonly 15-30% | Absorbed inside the fixed increment |
| Realistic total | $98,000 to $107,000 | $104,350 |
The point of the table is not the specific figures, which will be wrong for your situation. It is the shape: a quote that looks like a third of the price converges once the uncounted hours are counted, and the remaining difference is small enough that it should be decided on fit rather than on price. Run the same arithmetic with your own numbers and it will tell you something a rate card cannot.
Questions that surface these costs before you sign
- 1
Ask what the vendor needs from you, in hours per week, from named people. A vendor who says almost nothing has not thought about it.
- 2
Ask what happens when a developer hits a question the specification does not answer, and how long the answer typically takes.
- 3
Ask for the acceptance criteria on a real increment before signing, and check whether you could tell from them that the work was correct.
- 4
Ask who writes down a business rule discovered in conversation, and where it lives afterward.
- 5
Ask what a defect found in production two months after acceptance costs, and who pays for it.
The answers matter less than whether the vendor has clearly been asked before. These are the mechanics of delivery, and a team that has not thought about them carefully has not run many engagements that went badly, which is a different thing from having run many that went well.
Common questions
- Is this just an argument that offshore development is bad?
- No. It is an argument that the comparison is usually made on an incomplete number. Offshore delivery is often the correct commercial answer, particularly for well-specified work with a stable definition of done. The failure is comparing a vendor invoice against a vendor invoice when a significant part of one option's cost lands on your own staff instead.
- What is a realistic multiplier on a low-rate quote?
- For discovery-heavy operational work, 1.4x to 2x the quoted figure once internal hours and one rework cycle are counted. For well-specified work against a good document, closer to 1.1x. The variable is not geography; it is how much of the requirement exists in writing before anyone starts.
- Do these costs disappear with a US-based team?
- Several shrink and none vanish. Specification effort and acceptance testing are lower because the team can do more of the analysis themselves and in your environment. Decision latency largely disappears on a shared working day. Rework falls but does not reach zero, and any vendor claiming otherwise is selling. Coordination overhead depends on team size rather than location.
- How do we budget for rework honestly?
- Assume one cycle on anything where the requirement was written before the work started, and size it at 15 to 30 percent of the original increment. If it does not happen, you have a pleasant surprise. Budgeting zero rework on discovery-heavy work is the single most common reason software budgets are described as overruns when they were really underestimates.
- We do not have the internal hours this implies. What then?
- That is an argument for a delivery model that needs fewer of them, not for a cheaper rate. If nobody on your side can write a specification or answer questions daily, a model priced against a specification will fail regardless of what it costs per hour. Start with a small discovery increment whose output is the specification itself.