When our rate lands next to a larger agency's, we're usually higher per hour. Sometimes considerably. There's no version of this conversation where we win on the hourly number, so we'd rather explain what the number is actually made of.
The standard agency staffing model is a pyramid. One principal or architect across several accounts, a couple of mid-level engineers and a base of juniors doing the volume. It's presented as a delivery structure. It's a margin structure. Juniors are billed at a multiple of their cost, seniors at a smaller multiple, so the shape of the team is set by the shape of the P&L before anyone looks at the project.
That model made sense when the base of the pyramid did work that had to be done by someone and didn't require judgement. Boilerplate, CRUD screens, test scaffolding, the long tail of small components. Real work, high volume, low decision content.
That work is now substantially automated. What remains is disproportionately the work the pyramid was worst at.
The arithmetic
Blended rates hide this, so take a simple version. A twelve-week build.
Pyramid team. One architect at 20% allocation, two mid-level engineers, three juniors. Blended rate is attractive. Twelve weeks quoted.
Senior team. A tech lead, a design lead, a project manager, all substantially allocated. Blended rate is 40-60% higher. Eight weeks quoted.
Eight weeks of expensive people frequently costs less than twelve weeks of a blended team. That's the headline, and it's not the main effect.
The main effect is rework. On the pyramid project, a meaningful share of the junior output gets rewritten: by a senior, later, under deadline pressure, after it's been integrated with other things. Not because juniors are bad. Because a junior producing a plausible solution to a subtly wrong understanding of the requirement is the single most common way software projects lose weeks, and the architect at 20% allocation is not present often enough to catch it early.
Rework doesn't appear on the invoice as rework. It appears as the project taking longer than quoted.
Then there's the compounding cost, which nobody quotes at all. A decision made badly in week three gets more expensive to reverse every week it survives: a data model that can't express a case you'll need, an auth approach that won't extend to SSO, a component structure that fights every subsequent screen. Senior time is front-loaded specifically because that's when the expensive-to-reverse decisions get made. A pyramid puts its thinnest senior coverage exactly where a wrong call costs the most.
Where the pyramid is genuinely the right answer
It would be dishonest to argue this is universal, and you should be sceptical of anyone who does.
Large, well-understood scope. A hundred screens against a settled design system and a stable spec. The decisions are made; the work is execution at volume. A pyramid is efficient here and a senior-only team is overpriced.
Long-running maintenance of a mature system. Once the architecture is set and the change rate is low, you're paying for availability more than judgement.
Where you're building a team as well as software. If the goal includes growing an in-house team, juniors on the project is the point.
When the budget won't stretch. A cheaper team that ships something beats a better team you can't afford. Real constraint, and it deserves a straight answer rather than a lecture.
The case for senior-only is strongest in the opposite conditions: unclear scope, decisions still open, a first version where the architecture will be lived with for years, a timeline where a lost month matters. Which describes most MVPs and most first builds: the work we do.
What we actually run
A senior triad on every project: tech lead, design lead, project manager. Not a rotating cast, and not one senior spread across five accounts.
The reason it's three rather than one is that the three most common ways a project fails are architectural, experiential and organisational, and they need different people. A brilliant tech lead does not prevent a product that's confusing to use. A strong designer doesn't prevent a stakeholder alignment failure. Most projects that go wrong go wrong in the seams between those three, which is exactly where a thin senior layer has no coverage.
Team size is around 15 people. That's deliberate, not a stage we're passing through. Past a certain size, an agency needs a pipeline of juniors to feed the pyramid, and the model changes whether anyone intends it to.
What to ask when you're comparing quotes
The hourly rate is close to the least informative number in a proposal. Better questions:
"Who specifically works on this, what percentage of their time and for how many weeks?" Names and allocations. "A senior architect oversees the project" can mean four hours a month.
"What's your rework rate, and how do you know?" Most agencies have never measured it. The reaction to the question tells you as much as the answer.
"If the estimate is wrong, who absorbs it?" This is the rate conversation in its honest form. A low rate with a long timeline and change requests is expensive; a high rate with a firm scope may not be.
"Which decisions get made in the first two weeks, and by whom?" The answer tells you where the seniority sits.
And the arithmetic that matters more than any of them: total cost to a working product, plus your best estimate of what six months of living with the result will cost. An agency that won't engage with that comparison is telling you which number they'd rather you looked at.
The part that's changing
This argument gets stronger every quarter, and not because senior engineers got better.
As more of the volume work is automated, the proportion of a project that consists of judgement rises. A team structure optimised for producing volume cheaply is optimised for the part that's disappearing. The pyramid isn't wrong so much as it's solving a problem that's shrinking.
We'd rather quote a higher rate and a shorter timeline and be judged on the total. It's a harder sell in the first meeting and an easier one in the second.
Comparing proposals? Tell us about your project and we'll walk through the arithmetic on yours, including the parts that don't favour us.
Was this useful?