the commercial argument

You need a system built. The quote doesn't work

Not because anyone is cheating you — a team of five costs what a team of five costs. But you may not need a team of five. This page is the honest arithmetic behind that claim, including where it stops being true.

the situation you're probably in

Any of this sound familiar?

diagnosis.logpick the one that stings

        // the number is more than the problem is worth
        You know what you need. The quote you're holding costs more than the thing will earn you in its first two years, and the timeline puts it beyond the window where it mattered.

        // you've been burned once already
        Something was delivered. It half works, nobody can explain how, and the people who built it are gone. You're wary of starting again with anyone.

        // you can't tell who's competent
        Every proposal reads the same. All confident, all vague, all quoting different numbers for the same brief, and you have no way to judge between them.
      

the obvious question

How is one person cheaper and faster than a team?

Two things, and they compound.

First, the work that used to need the rest of the team now takes a fraction of the time. That part everyone has noticed, and it is real.

Second, and this is what decides your delivery date: a saving only reaches you if nothing eats it on the way. Look at what you're being quoted for. Some of it is people building the thing. The rest is the structure around them: the estimate that waits three weeks for four people to agree, the fortnightly progress meeting, the handover document, the ticket sitting idle for a reviewer who's on another project, the change request that goes back through commercial. None of that was ever a tooling problem, so none of it got faster, and on a conventional build it is a large share of the calendar. With one person deciding, that layer is absent. The time the tools save lands on your date instead of being absorbed on the way to it.

Twenty-two years is what makes that safe rather than reckless. The honest version: these tools produce an enormous amount of code very quickly, and a meaningful proportion of it is subtly wrong in ways that only show up under load, under attack, or eighteen months later. Handed to someone junior, that's a disaster you'll pay for twice. Handed to someone who has spent two decades finding exactly those failures, it's leverage.

So: the architecture is mine, decided before anything is generated. The implementation is accelerated hard. What I read closely is where the risk actually sits — authentication, permissions, the data model, anything at a system boundary — and the rest is proven by behaviour, under test against the specification. There is no part of what I hand over that I can't sit down and explain to you.

You're not paying for typing. You're paying for the judgement about what to keep.

$ read-the-full-method

the rule

What beating your quote actually means

Send me the quote you're holding. If it's a written, fixed-price quote from a named vendor for a scope I can match, you'll get a straight answer inside the week — usually sooner — on whether I can do it better and roughly by how much. That costs you nothing.

What usually comes back: around half the price, and materially faster — typically up to half the elapsed time. That's the pattern, not a promise. It's what the arithmetic above tends to produce once the coordination overhead comes out, and I'd rather describe it honestly than sell it as a guarantee I'd have to weasel out of on the one job where it doesn't hold.

Because sometimes it doesn't. Some quotes are already keen and there's nothing in them left to take out. Some work genuinely needs more than one pair of hands. When either is true you'll hear that from me just as quickly, and the right answer is to take the quote you already have.

The indication is free; the firm number isn't guesswork. Your quote is the benchmark the price gets set against, and the fixed version comes out of a signed specification — a paid piece of work in its own right. Nothing is committed on either side before that document is signed.

$ how-the-number-gets-set $ read-the-spec-engagement

where the arithmetic breaks

When a team really is the right answer

The saving comes from removing coordination overhead and compressing implementation. Neither of those helps you when the constraint is something else — so here is when the number in your hand is the correct number, and you should pay it.

When the work genuinely needs parallel hands.

Some scopes are large enough that no single person should carry them, however fast the tools are. If that's yours, I'll tell you rather than take the contract and miss the date.

When you're buying redundancy, not code.

If your risk position requires a vendor who survives an individual being unavailable, that's a legitimate requirement and I don't meet it. An agency does.

When nobody knows what it should be yet.

Fixed price needs fixed scope. Discovery is real work, and it's honest work — it's just billed differently, and pretending otherwise is how projects go wrong.

get in touch

Send me the problem, not a brief

A paragraph in plain language is enough — what you're trying to build and why it matters. If you've been quoted already, send that too. You'll get a straight answer, usually well inside a week: whether I can do it better, roughly by how much, or that I'm not your answer.

$ mail --to quoteme@definitionofdone.dev