The $35/hr engineer who costs $110/hr, and how to do the math properly

The rate card is not the cost

An hourly rate tells you what a vendor charges for an hour of work. It tells you almost nothing about what a feature will cost to ship, run and maintain. Those are different numbers, and the gap between them is where most budgets go wrong.

The rate is attractive because it is the one figure everyone agrees on up front. A $35/hr engineer looks like one third of a $100/hr one. But you do not buy hours. You buy working software that behaves in production, and the price of that depends on how many hours actually turn into shipped work, who else has to be in the room, and how often you replace people along the way.

We price every engagement on total cost, not rate. Below is the model we use, with the multipliers written out. The numbers here are illustrative, not quotes. The point is the method, so you can run it against any vendor, including us.

Four multipliers nobody quotes you

Start with the rate, then apply the factors that the rate card leaves out.

• Rework (about 1.3 to 1.5). Work that ships, gets rejected in review or QA, and comes back. Thin test coverage and loose requirements push this up. A team that reviews its own code and writes tests keeps it near the low end.
• Management overhead (about 1.2 to 1.4). The hours you or a delivery lead spend writing tickets, clarifying, and checking output. A rate that needs heavy supervision is not as cheap as it looks, because your time has a cost too.
• Overlap drag (about 1.2 to 1.6). When your day and the team's day barely touch, a question that should take ten minutes takes a day. Each round trip adds calendar time, and calendar time is money on a fixed deadline.
• Churn (about 1.1 to 1.3). When people rotate off, their replacement spends weeks learning what the last person knew. You pay for that ramp twice: once in their hours, once in the slower delivery around them.

None of these appear on an invoice. All of them appear in the total.

A worked example (illustrative)

Take the headline rate of $35/hr and apply mid-range multipliers:

$35 × 1.4 (rework) × 1.3 (management) × 1.7 (overlap drag) ≈ $108/hr effective

The nominal $35 is real. So is the $108. One is the price of an hour; the other is the price of an hour of shipped, reviewed, maintainable work delivered against your calendar. A $90/hr engineer with tight review habits, strong overlap and low churn can land near $110 effective too, which is why rate alone never settles the question. You have to compare the effective number.

This is also why cutting the rate in half rarely halves the bill. If the cheaper option carries higher rework and worse overlap, the multipliers eat most of the saving, and you absorb the difference in missed dates and your own time.

How to compare vendors on total cost

You can run this comparison before you sign anything. Ask each vendor five concrete questions:

1. Who writes the code, and who reviews it? Named people, with review built in, keeps rework down.
2. How many hours of your time does a typical week need? That is your management multiplier, and it is part of the price.
3. What is the daily overlap with our working hours? More overlap means fewer lost days per decision.
4. What is your team's turnover, and who owns handover when someone leaves? This is your churn exposure.
5. What do we own, and when? If the code, accounts and documentation are yours from week one, your switching cost stays low, which caps the downside on every other factor.

Put the answers into the multipliers and compare effective rates, not headline ones. A vendor that is more expensive per hour and cheaper per shipped feature is the cheaper vendor.

Where this model does not fit

This math is built for sustained product work, where rework, overlap and churn compound over months. It is the wrong lens for a few cases.

For a one-week spike or a throwaway prototype, the rate basically is the cost, because none of the long-run multipliers have time to bite. For work with no deadline pressure, overlap drag matters far less, so a cheaper, loosely-overlapping team can be the right call. And if your own team can absorb the management and review load at no real cost, that multiplier shrinks for you specifically.

We would rather tell you when the simple rate comparison is good enough than sell you a model you do not need. When the work is sustained and the deadline is real, though, compare total cost. The rate card is the start of that calculation, never the end of it.