Two proposals land on your desk. Both promise senior engineers, both quote a rate, both come with logos and case studies. The documents are nearly identical because the documents are not where the difference lives. The difference is the specific human beings who will make architectural decisions inside your codebase — and a rate card is designed to keep you from looking at them. So before any contract is signed with us, you interview the tech lead who will run your team.
Rate cards hide the people
A rate card prices a category: “senior engineer”, “QA lead”. But the entire risk of buying engineering services lives in the variance the category averages away. Two engineers with the same title and the same rate can differ enormously in judgement, in how they handle an incident, in whether they push back on a bad requirement or quietly implement it. Software is built by individuals; a rate card is a promise about averages. You would not hire an employee from a job title alone, yet that is exactly what a blended proposal asks you to do — for the people who will hold the keys to your product.
Named squads, not blended rates
Our model removes the averaging. You get a named squad at a fixed monthly team fee per named engineer — no blended rate, no anonymous pool behind the number. Named means accountable, and accountable means interviewable. If we are claiming that a particular person will own your architecture, you are entitled to check that claim yourself, before money moves. The interview is not a courtesy; it is the proof mechanism for everything else in the proposal.
What to actually ask in that interview
The hour is only useful if it goes past pleasantries. These are the questions we think a client should put to any tech lead — ours included — because they are the ones weak partners cannot survive:
- “Walk me through the last production incident you handled.” — You are listening for ownership and specifics: what broke, what they did at two in the morning, what changed afterwards. Polish is a bad sign; detail is a good one.
- “What would you push back on in our current architecture?” — Send material in advance. A lead who has read it and disagrees with something is worth more than one who agrees with everything.
- “How does a change get from spec to production on your team?” — You want review gates, tests, and a named person who signs the merge. A diagram of ceremonies is not an answer.
- “What is in your definition of done?” — Listen for documentation, decision records and handover. If done means “code merged”, you will pay for the difference during maintenance.
- “How does AI-written code get reviewed?” — Every serious team uses AI tooling now. The question is whether machine-written code faces the same bar as human-written. On our teams it does: an engineer signs every merge, whatever produced the diff.
- “Who exactly will write the code, and will they still be here next year?” — Then get the answer written into the contract, not the sales deck.
- “Tell me about a technical decision you got wrong.” — Judgement shows itself at failure. Someone who cannot name a mistake has either never led anything or will not tell you when it happens to your system.
The people you meet are the people who show up
The classic failure of this industry has a simple shape: seniors do the sales calls, juniors do the delivery, and the blended rate makes the substitution invisible. The interview is worthless if the cast changes after signing — which is why the second half of our promise matters as much as the first: nobody is swapped mid-engagement to a cheaper profile. The lead you grilled is the lead who runs your squad, and the squad you were named is the squad that writes the code. That sentence sits in how we sell precisely because the trick it rules out is that common.
The interview filters both ways
Honestly: this costs us deals. Some prospects want a signature this week and a team next week, and an interview step slows that down. We keep it anyway, because it filters in both directions. A client who will not spend an hour with the person about to own their architecture is telling us how the engagement will be run. A tech lead who cannot hold that room is telling us something too. Both signals are cheap at the price — an hour — compared to learning the same facts six months into a contract.
Whoever you end up choosing, put a tech-lead interview into your evaluation — the question list above works on anyone. And if you would like to run it on one of ours, that is exactly how our engagements start: a technical call, not a sales call.