How to evaluate an engineering partner’s real cost

The hourly rate is the first thing a buyer compares when choosing an engineering partner, and the least useful. It is visible and precise, which is exactly why it misleads. A product gets built over thousands of hours, and what those hours produce, and whether the work has to be done again, is where the cost actually lives.

We do not compete on rate. We compete on what an engagement actually costs you over the life of the product. Those are different numbers, and the gap between them is the whole subject here.

This is where the real cost hides, on both ends of the rate scale, and how to read it before you sign.

Key Takeaways

• The hourly rate is the most visible cost of an engineering partner and the least informative.
• A low rate can hide rework and churn. A fine-looking rate can hide a team that overpromises and cannot deliver. Both cost more than the rate.
• Rework is the biggest hidden tax: developers lose about 42% of their time to maintenance and bad code (Stripe), and 10 to 20% of new-product budgets go to tech debt (McKinsey).
• Continuity is the antidote. On the Inside Real Estate engagement, eight years with zero full-time engineering turnover meant no re-ramp and no rotating bench.

Because the rate prices an hour, and the project is built over thousands of them. A low rate that comes with rework, turnover, and hand-holding costs more per shipped feature than a higher rate that does not. The number worth comparing is cost per outcome over the life of the product, which the rate on the proposal barely predicts.

The rate is attractive precisely because it is the one figure that lines up neatly side by side. Everything that actually drives cost, how good the code is, whether the team stays, whether they tell you the truth, is harder to see on a proposal. So buyers anchor on the rate and meet the rest later.

Mostly rework. Cheap or rushed delivery produces code that costs more to live with, and that cost is large and well documented. Developers already lose about 42% of their time to maintenance and bad code, by Stripe's 2018 Developer Coefficient, and McKinsey found 10 to 20% of the budget for new products gets diverted to paying down tech debt. A low rate that adds to that pile is a poor trade.

A low rate often comes from a rotating bench. When the people change every few months, you pay to teach each new person your system, and that knowledge tax never shows on an invoice.

It can also come from junior backfill. The senior who sold the work is rarely the one doing it, so you pay a blended rate for a senior pitch and junior delivery.

And when a partner builds to spec and hands it back, ownership of the outcome stays with you. Your team becomes the integration layer, and your time is the most expensive in the room.

The opposite failure costs just as much: a respectable rate attached to a team that overpromises and cannot do the work. The rate says nothing about competence or honesty, and those are what you are actually buying.

We have seen this cost land on someone we think the world of. Before dashCMA became the product it is now, Karen Abram had spent months with a team that kept telling her the hard part was solved. The listing data came in wrong, rentals arriving as homes for sale, and the things she asked for next, all of them achievable, came back as impossible. She made the call good founders make: she pulled the work and started fresh. The months were already gone. That lost time never appeared as a line item, and it was the most expensive part of the project.

What that team called impossible became the product she sold to Inside Real Estate eighteen months later. The full story is in how we took dashCMA from a founder's vision to acquisition. Her prior team's rate was never the problem. The problem was a team that promised what it could not build, and that cost landed in lost months, where no invoice would ever show it.

Yes, and it is the largest lever of all. The team that knows the code is the cheapest team to keep, because every other arrangement pays the knowledge cost again. On the Inside Real Estate engagement, eight years with zero full-time engineering turnover on the account meant no re-ramp, no rotating bench, and decisions that held because the people who made them were still there.

Continuity removes the exact costs a low rate hides. There is no monthly re-teaching, no rebuild when the people who understood the system leave, no slow erosion of why things were built the way they were. We wrote about how that holds even across an acquisition in what eight years on one codebase teaches you about M&A.

Stop comparing rates and start comparing cost per outcome. A short set of questions gets you most of the way, and you can ask them of anyone, including us:

• Who actually writes the code? Is the senior who sold the work the one doing it?
• Does the team stay? What is their turnover on a single account, over years?
• Who owns the architecture and the outcome, you or them?
• What will rework and re-ramp cost over the life of the product, not the first sprint?
• Will they tell you when something is a bad idea? A team that only ever agrees is expensive.

None of this means pay the most. Rate is real, and senior depth does not require US onshore prices, where senior engineering runs $150 to $250 an hour and up. Senior depth at a fair rate, from a team that stays, is the goal. The work is to weigh the whole cost over the life of the product.

Knowing where a heavy cost is worth it, and where it is wasted, is most of what senior engineering judgment is. It is the work we do as an ongoing engineering partner: a team that owns the architecture and stays with it, so the real cost stays low long after the rate stops being the interesting number.