I turned down a $480k contract. I'd do it again.

Last October, the biggest contract in Revin's history landed in my inbox. Six developers, twelve months, open-ended scope. I read it twice and said no. Here is what was in that proposal, why buying developer hours is the most expensive way to build software, and what happened next.

Por Victhor Araújo

Victhor Araújo

Last October, a Thursday, late afternoon. A proposal lands in my inbox that would have been, at the time, the biggest contract in Revin's history: $480k over twelve months. Six developers, immediate start, "we'll handle the management on our side".

I read the scope twice and asked for a call. On the call, I thanked them and said we wouldn't do it. The partner on the other side went quiet for about three seconds, then asked if I had understood the number. I had.

This piece is about what I saw in that proposal. And about why buying developer hours is the most expensive way to build software, even when the spreadsheet says otherwise.

The proposal looked great on paper. Paper, as always, will accept anything.

What was in the proposal

Six developers "allocated", daily standups run by their head of product, a backlog spreadsheet with 214 rows, and one sentence I still remember: "we'll figure out the scope as we go". The head of product, for the record, had never managed an engineering team in his life. Smart guy, good intentions, genuinely excited about the product. He had just never done this before.

No definition of done. No acceptance criteria. No technical owner. There were six seats and a monthly payment schedule, impeccably punctual.

On paper, classic staff augmentation. In practice, a body shop with a new badge: seats filled, accountability nowhere. And Revin doesn't sell body shop. Never has.

I've seen this movie before (three times, to be precise)

When you buy hours, the vendor gets paid for presence, not outcomes. Their incentive becomes keeping the seat warm. Nobody says it out loud, of course. But the script never changes:

• Months 1 to 3: honeymoon. High velocity, pretty demos, everyone complimenting everyone on Slack.
• Month 4: a technical decision stalls, waiting on someone who does not know how to make it. The team starts "getting ahead on other things".
• Month 6: a developer gets swapped "to optimize cost". The system knowledge walks out the door with him.
• Month 9: someone on the board suggests an external audit. That is the project's death certificate.

I know because Revin has been hired three times to run exactly that month-9 audit. The last one, at a logistics company, we found 11,000 lines of code without a single test and a deploy that depended on one specific developer's laptop. I wish I were exaggerating.

If your operation is somewhere on that timeline, Revin's Diagnostic Sprint does in two weeks what the month-9 audit does too late: code on the table and a report your CFO can actually read.

🧾 The math nobody does in front of the client

$480k for six developers over twelve months comes to about $6,600 per developer per month. For senior nearshore talent, that is a fair price. The price was never the problem. The rework that never shows up in the spreadsheet is.

Across the projects we have rescued in the last two years, average rework in the first six months was 38%. Apply that to $480k: roughly $182k spent building the wrong thing, or building the right thing twice.

Almost two hundred grand. To save the cost of one tech lead.

The calculator will accept any scenario you type in. Rework doesn't show up in any of them.

What we offered instead

Our counter: a four-person squad with a tech lead, a full operating ritual (planning, weekly stakeholder review, biweekly board report) and phased delivery against a definition of done written before the first sprint. $348k for the year. Fewer people, less money for me, more working software for them.

To be fair: there are cases where buying hours works. If you have a strong CTO, an engineering process that already runs, and you just need extra hands for a few months, staff augmentation does the job and costs less. This client had none of that. And honestly, most do not.

They did not sign. They went with an agency that took the deal exactly as written, all six seats.

The epilogue, because there is always one

This past March, the same partner reached out again. The project was "paused for reassessment". He asked if the squad proposal was still on the table. It was. We start in July, with the squad of four.

I am not telling this story to look principled. I am telling it because the market trained founders to buy software like a commodity: by the hour, by the head. Software is not a commodity. Whoever sells you warm seats is not on your side, however friendly they sound on the call.

If you are weighing the two models right now, we wrote an honest comparison, including the scenarios where each one wins: managed squads vs. staff augmentation.

And if you want an opinion on your specific case, book 30 minutes with me. No deck, no pitch: I take these calls personally.