~/definitionOfDone.dev/the-quote.md

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?

Because I use AI to do the work that used to require the rest of the team — and because 22 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

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 within a week: whether I can do it better, roughly by how much, or that I'm not your answer.