The Multiplier Nobody Quotes: Why Outsourcing Costs 30-60% More Than the Rate You Agreed

The Comparison Everyone Runs Is Structurally Broken

The global software development outsourcing market reached roughly $618 billion in 2026, and an enormous share of the buying decisions inside it are made by comparing hourly rates in a spreadsheet. It is the most natural thing in the world to do, and it is almost guaranteed to produce the wrong answer, for a reason that has nothing to do with vendor honesty.

An hourly rate prices one input: an engineer's time, as billed. It does not price the time your own people spend managing that engineer, the weeks before they become productive, the cycles lost to rework, the delay introduced when a question waits overnight for an answer, or the cost of replacing them when they rotate off. Those costs are real, they are paid by you, and they vary enormously between vendors — which means comparing two rates without them is comparing two numbers that measure different things.

Published outsourcing cost analyses put the true cost 30-50% above headline rates once onboarding, management, QA cycles and timezone overhead are counted, with total cost of ownership reaching as much as 60% above the rate — and they consistently identify rework, QA gaps and unclear ownership as the dominant drivers, ahead of developer rates entirely. Regional benchmarks reinforce how wide the spread is: offshore development at $20-45 an hour against $80-150 for US in-house, Eastern European rates in the $40-80 band, nearshore Latin America at $50-100, North American onshore at $100-200.

The purpose of this piece is to make those numbers comparable. Not by arguing that expensive vendors are secretly cheaper — sometimes they genuinely are not — but by giving you the seven lines that turn a rate into a cost, and a worked example showing how much the ranking moves.

The Seven Lines That Never Appear in the Quote

Every one of these is paid by you. None of them appear on an invoice from the vendor, which is precisely why they escape the comparison.

Ramp-up. A new engineer on an existing codebase reaches full productivity somewhere between six and twelve weeks, and you pay full rate throughout. On a twelve-month engagement, a ten-week ramp at 50% effective output is roughly 10% of the annual cost, gone before anything ships. The variable that moves this most is not vendor quality — it is whether the engineer stays for three years or eight months, because the ramp is paid again on every replacement.

Internal management overhead. Somebody on your side writes the tickets, answers the questions, reviews the output and runs the ceremonies. For a team of five, that is realistically a quarter to a half of a senior person's time — €25,000 to €50,000 a year of your own payroll that exists only because the work is outsourced. Vendors that require detailed specification consume more of it; senior teams that operate from outcomes consume less.

Rework and QA cycles. The single largest line, and the one with the widest variance. Work delivered against a misunderstanding gets rebuilt, and the cost is not just the rebuild — it is the review cycle that caught it, the schedule slip, and the trust erosion that makes the next specification longer.

Timezone friction. Every question that cannot be answered within the working day costs a day of latency. On a nine-hour gap this compounds into a measurable velocity tax; with four hours or more of overlap, most of it disappears. This is not an abstract concern about culture — it is a queueing cost, and it is proportional to how many decisions a project needs.

Tooling and licences. Seats for your issue tracker, CI, observability, security scanning, and increasingly the AI coding tools, which have moved to usage-based pricing and become one of the least predictable line items in an engineering budget. Clarify who pays. It is a surprisingly common source of month-four friction.

Turnover and rotation. When a vendor rotates an engineer off your account, you pay for the new ramp and lose accumulated context that nobody wrote down. Bench-staffed models rotate more than named-engineer models. This is where cheap engagements quietly become expensive.

Exit and transition. At some point the engagement ends. If knowledge lives only in the vendor's heads, transition costs months. Contractual documentation and handover obligations are cheap to negotiate before signature and nearly impossible after.

The Worked Example

Two real-shaped quotes for the same twelve-month product engagement. Vendor A is offshore, quoting five engineers at €28 an hour. Vendor B is nearshore, quoting three senior engineers at €50 an hour. The scope is identical.

On headline rates: Vendor A is 5 × 160 hours × €28 = €22,400 a month, or €268,800 a year. Vendor B is 3 × 160 × €50 = €24,000 a month, or €288,000 a year. Vendor A wins by €19,200 and this is where most decisions get made.

Now apply the multipliers. Vendor A: a ten-week ramp across five engineers at partial output (~10% of annual cost, €27,000); internal management at 0.5 FTE because five mid-level engineers need detailed specification and review (€40,000 of your own payroll); rework at 15% of delivered work, which is what a nine-hour gap and specification-driven delivery typically produces (€40,000); timezone latency costing roughly one day per blocking question with an estimated velocity impact around 8% (€21,000); and one rotation during the year with its own ramp (€12,000). Total additions: €140,000, a 52% multiplier. True twelve-month cost: €408,800.

Vendor B: a six-week ramp across three engineers (€17,000); internal management at 0.25 FTE because senior engineers work from outcomes rather than tickets (€20,000); rework at 6%, reflecting same-day clarification and seniority (€17,000); negligible timezone latency with four-plus hours of overlap (€6,000); no rotation, because engineers are named and contractually stable (€0). Total additions: €60,000, a 21% multiplier. True twelve-month cost: €348,000.

Vendor B, which looked €19,200 more expensive, is €60,800 cheaper in reality — and that is before counting the option value of the knowledge staying in the same three heads for year two. The multipliers used here are not adversarial; they sit inside the published 30-60% range and the low end is deliberately generous to Vendor A. Run the same arithmetic with your own assumptions and the direction of the result is remarkably stable.

The point is not that nearshore always wins. Change the inputs — a well-specified maintenance workload with low decision density, a vendor with genuinely low rotation, a scope that does not need architectural judgment — and the offshore quote wins on TCO too, honestly and by a wide margin. The point is that you cannot know which without running the model, and almost nobody runs it.

Rework Is the Line That Decides It

Of the seven lines, rework has both the largest magnitude and the widest variance between vendors, so it deserves separate treatment. Everything else is arithmetic; this one is diagnosis.

Rework has three distinct sources and they need different fixes. Misunderstanding — the vendor built what the ticket said rather than what you meant — is a communication-latency problem, and it correlates directly with timezone overlap and with whether the engineer has enough context to notice that a requirement is odd. Under-specification — the ticket genuinely did not say — is a seniority problem: a senior engineer asks before building, a junior builds and waits for review. And quality rework, where the code works but is unmaintainable, is a review-standards problem that compounds silently until it becomes the reason feature velocity halves in year two.

The reason rework has grown as a share of total cost is worth stating plainly. AI assistance means more code arrives faster, and the constraint has moved decisively from writing to verifying. A vendor whose output volume doubled while its review discipline stayed constant is shipping you more rework, not more value, and the invoice looks identical either way.

You can measure this before signing, which is the useful part. Run a small paid pilot — two to four weeks, a real feature, your actual codebase — and count three things: how many delivered items needed material revision, how many clarifying questions arrived before work started rather than after, and how long a blocking question took to resolve. Those three numbers predict your rework multiplier better than any reference call, and a vendor unwilling to be measured on a paid pilot has told you something important for the price of a fortnight.

The 2026 Distortion: Paying Per Hour for AI-Accelerated Output

There is a newer problem the classic TCO model does not capture, and it is quietly reshaping what an hour means.

Your vendor's engineers use AI assistance. Their output per hour has risen materially — the delivery data across the industry is not ambiguous about that. If the contract is time-and-materials at a fixed rate, every unit of that gain accrues to the vendor, and the buyer's cost per unit of delivered functionality is unchanged. That is not fraud; it is simply what a T&M contract does. But it means the rate you negotiated in 2024 buys a different thing in 2026 than it did when you agreed it, and nobody has renegotiated.

The second-order effect is worse than the first. If a vendor's revenue is a function of hours, and AI reduces the hours a task requires, the commercial incentive points toward larger scopes rather than faster delivery. Most vendors do not act on that incentive, but you should not have to rely on their forbearance when the contract can be structured so the incentives point the same direction as your interests.

The practical responses are unglamorous and effective. Renegotiate at renewal with productivity data in hand rather than assertions. Shift the parts of the scope that can be defined by outcome onto outcome pricing — a delivered, tested, deployed capability rather than a headcount-month. Ask directly what AI tooling the team uses, who pays for it, and what the vendor's own review process is for AI-generated code, because that answer tells you whether the throughput gain is arriving as delivered value or as rework you will pay to fix. And put a code quality clause in the contract with a concrete standard, since "passes tests" stopped being a meaningful bar when generating tests became free.

Contract Terms That Keep the Model Honest

A TCO model is a forecast. These five clauses are what make the forecast hold, and each maps directly to one of the seven cost lines.

Named engineers with a substitution clause. The contract should name the individuals, require your written consent before substitution, and specify a minimum notice period — thirty days is standard and achievable. This is the single most valuable term available to you, because it converts rotation from a vendor decision into a negotiation, and rotation is where the ramp cost gets paid repeatedly.

A ramp-rate concession. Many good vendors will bill the first four to six weeks at a reduced rate, on the reasonable basis that you are not receiving full output. Vendors who refuse outright are telling you they expect ramp to be short or they expect to bill you for it regardless; either answer is informative.

A rework definition. Define what counts as work delivered against an agreed specification that fails to meet it, and state that correcting it is not billable. This sounds confrontational and is in practice completely standard among vendors who are confident in their delivery. The conversation it produces during negotiation is worth having regardless of where it lands.

Documentation and exit obligations. Architecture decision records, runbooks, and a defined handover package as an ongoing deliverable rather than a final-month scramble. Tie a modest payment tranche to it if you want it to actually happen.

Overlap hours as a service level. If four hours of overlap is what your engagement needs, write it in as a commitment rather than an expectation. It is the cheapest term in the contract and it removes the most common source of month-three friction.

Running the Comparison Properly

The full procedure, start to finish, is about two weeks of work and it is the highest-return two weeks in the entire procurement.

Normalise scope first. Take the most detailed proposal you have received, extract its scope, and send that as fixed scope to every vendor. Most price variance on a shortlist is scope variance wearing a disguise, and this step removes it before you build any model.

Build the seven-line model for each vendor with vendor-specific assumptions, not a flat multiplier. Ramp length depends on team size and codebase complexity. Management overhead depends on the seniority you are buying. Rework depends on overlap and seniority together. Rotation depends on the staffing model — bench or named. If you have no basis for an assumption, ask the vendor and note their answer; how they respond to being asked is itself signal.

Then run a paid pilot with the top two, on real work, and replace your assumed rework and latency numbers with measured ones. This is the step that converts a spreadsheet into a decision, and the cost of it is trivially small against the size of a twelve-month commitment.

At StepTo we have run senior engineering teams out of Serbia since 2014, and we price this way because the model consistently favours the structure we already run: senior engineers assigned by name who stay with a codebase, four or more hours of overlap with Western European hours as a default rather than a concession, and small teams that operate from outcomes instead of ticket specifications. It is not the cheapest hourly rate on most shortlists and we do not present it as one. Our outsourcing cost analysis and cost calculator both model total cost of ownership rather than rate cards, our pricing is published rather than quoted on request, and we would rather lose a deal to a model you ran yourself than win one on a comparison that was never valid. If you want the engagement structured so the multiplier stays low by construction, a dedicated development team is the shape that does it.