Software as Leverage

The agency ceiling is arithmetic, not strategy

An agency's revenue is headcount multiplied by rate multiplied by utilisation. Every one of those three numbers has a ceiling, and the ceilings are close together. You can hire, but hiring adds management before it adds margin. You can raise rates, but only until the client with a budget goes elsewhere. You can push utilisation, but the last ten percent is taken out of the quality of the thinking, which is the thing being bought.

So the agency that has been going ten years looks a great deal like the agency that has been going three, with more staff. Nothing compounds. Each project starts at zero, is delivered, and is handed over. What was learned stays in the heads of whoever happened to be on it, and leaves when they do.

This is not an argument that agencies are bad businesses. They are perfectly good businesses. It is an argument that they are linear ones, and that people running them frequently believe otherwise.

Each project starts at zero, is delivered, and is handed over. Nothing compounds.

What actually compounds

Three things survive a project, and only three.

The first is infrastructure — not servers, but the parts you stop rebuilding. Payment handling that you trust because you have already got it wrong once and fixed it. Deployment that works the same way for every project. An admin layer that does not have to be reinvented for each client who needs staff to log in and do their jobs. The tenth project on a good foundation costs a fraction of the first, and the difference is entirely margin.

The second is judgement, written down. Knowing that a restaurant system has to keep working when the internet drops, that a booking has to be re-checked at the moment of payment and not before, that an owner will ask for a report in the second week that nobody scoped — none of this is clever. It is just expensive to learn, and most firms learn it repeatedly because they never write it down.

The third is ownership. If you keep a share of what you build, or build something of your own alongside the client work, the work stops ending when the invoice is paid.

The studio arrangement

A venture studio is a plain answer to an awkward problem: product work is where the compounding is, and product work does not pay this month.

Client work pays this month. It also does something less obvious and more valuable — it puts you inside real businesses, watching real operations fail in real ways, which is the only reliable source of product ideas. An enormous share of software is built by people who imagined the problem. Working for a hotel, a restaurant group and an architecture practice in the same year tells you which problems are actually shared, and a shared problem is a product.

So the arrangement is: take the client work, but take it in sectors where you intend to build. Reuse the infrastructure in both directions. And keep something of your own, so that some part of the business grows while you sleep.

We run it this way. Smartrav is ours — a travel platform that puts flights, hotels, transfers, car rental and connectivity into one search rather than five sites. NIL Card is ours — an operating system for student-athletes to price and sell their name, image and likeness, which had twenty athletes on it inside the first two days. Both were built on the same foundations we use for client engagements, and both exist because client work showed us what was missing.

Why small is the point

The version of this that fails is the studio that grows into an agency with a side project. Once headcount is high enough that the client work must be fed continuously, the product work is always the thing that gets postponed, and it is postponed permanently.

A small team has a genuine structural advantage that has nothing to do with being scrappy. A team of three that has built the same class of system a dozen times has no coordination cost, no handover loss, and no meeting where somebody explains the decision to somebody who will implement it slightly differently. What it lacks is capacity, and capacity is exactly what good infrastructure supplies.

This is why the leverage in the phrase is not a metaphor. Leverage is doing more with the same effort, and every hour spent making the foundation better is an hour that pays again on every subsequent project — client and product alike.

A team of three that has built the same system a dozen times has no handover loss. What it lacks is capacity, and capacity is what infrastructure supplies.

What it means for a client

This is not only an internal matter, and it is worth being direct about how it changes what you get.

You get a team that has solved your problem before, because the sectors are chosen rather than accepted. You get infrastructure that was hardened on somebody else's emergency. And you get a firm whose interests point the same way as yours — we would rather build you something that works for five years than something that requires us monthly, because our upside is not in your dependence.

The trade-off is real too. We will decline work outside the sectors we build in, and we will argue with a brief we think is wrong. A firm billing hours has no reason to do either.