~/definitionOfDone.dev/how-i-work/the-spec.md

how-i-work › the specification engagement

Scope before price, in full 

A fixed build price is only honest if what's being built is already written down and signed — and the signature that matters is mine. I'd rather build your system than write about it, so the best version of this engagement is the smallest one: you bring a specification that holds up, I verify it, close the gaps and put my name on it. How much of it I have to write is up to you, and it's the one part of this you can make cheaper.

what you get

One document, five parts, yours to keep

The output is a specification your next vendor could build from without ever speaking to me. Every part of it is decided by me and written up in plain language, with diagrams where they help.

spec.contentswhat the document contains
// architecture How the system is shaped: the services, what each one is responsible for, how they talk to each other, and what happens when any of them fails.   // data model What is stored, where, in what shape, and who owns each piece. The decisions here are the hardest to reverse later, so they're made first and written down.   // interface contracts Every boundary defined: the APIs, the events, the integrations with systems you already run. Request and response shapes, error behaviour, who is allowed to call what.   // infrastructure plan The AWS footprint, defined as code from the start: accounts, environments, networking, identity, deployment, and what it will cost to run.   // risk register What could go wrong, how likely it is, what it would cost you, and what the design does about it — ranked, so you know which ones to actually worry about.   // walkthrough A session with you, and your team if you have one, going through the document until there's no part of it you can't explain to someone else.

how it starts

From whatever you already have

Every hour I spend authoring your specification is an hour the system doesn't exist, and money you've spent before any of it runs. So the three starting points below are a ranking, not a menu — best first.

01

You have a detailed specification — first prize

Requirements, user flows, the systems it has to talk to, the constraints you're under. I read it, send back a short list of gaps and questions, close them with you, and counter-sign the result. The engagement is verification, not authorship: your document, my name on it. Fastest and cheapest route to a fixed build price there is, and the one I'd rather you took.

02

You have a partial one

Something exists but it wouldn't survive a hard question. I tell you what's missing and what it costs to close it: a fixed top-up on the bracket fee, quoted at intake, before any work starts. The thinner the document, the bigger that number — bringing detail is cheaper than paying me to extract it, and it stays that way.

03

You have nothing written down

Send me the problem in a paragraph anyway. Whether I take it on depends on the size of it — some things are worth building the specification from scratch and some aren't, and you'll get a straight answer either way rather than an open-ended discovery bill. Go in clear-eyed, though: this is the long way round. I write the whole document before anything gets built, which means you pay for all of it and wait for all of it.

what it costs

A fixed fee, set by the size of the system

USD 2,500smaller scope
fixed fee
USD 5,500substantial scope
fixed fee
50%of the fee credited
if you build with me
smaller scope

One system with clear edges.

A single service or application, one data store, a handful of integrations. The kind of thing one person builds in weeks, not months.

substantial scope

Several moving parts, or an existing one to untangle.

Multiple services, multiple integrations, more than one team touching it, or a legacy system whose behaviour has to be mapped before anything can be designed around it.

Bring a specification that holds up and the bracket fee is the whole of it. Bring a partial one and there's a fixed top-up on top, sized by how much is missing and agreed at the same time as the bracket. There are no day rates and no hourly billing on this — one number, in writing, before you commit, whichever starting point you're at.

Which bracket you're in is agreed at intake, before any work starts — if your partial specification turns out to describe something bigger than it looked, you hear that up front, not on the invoice. The fee is payable on commencement.

If you go on to build with me, half the specification fee comes off the build price. If you don't, the document is still yours, and the fee is the whole of what you've spent.

Anchored in USD and converted each quarter — the figures above are shown in whichever of USD, GBP, EUR or ZAR fits where you're reading from. Invoiced in the one we agree up front.

what's not included

Stated now, so it isn't a surprise later

Building it.

The specification is the input to a build quote — fixed price, fixed date — not the start of one. The build is scoped, priced and contracted separately, off the signed document.

Screens and user-interface design.

Wireframes, visual design and copy are not in scope. If the system has a front end, the specification defines what it talks to and how — not what it looks like.

Choosing your vendors for you.

The document is enough for any competent engineer or agency to quote against. Running that selection, or sitting in on it, is separate advisory work and priced as such if you want it.

Ongoing advice after sign-off.

Once the document is signed off and walked through, the engagement is done. Questions from a vendor working from it, or changes to the specification itself, are quoted separately — a fixed number, agreed before any of it is done. No open meter.

get in touch

Send me what you have

A specification, a partial one, or a paragraph in plain language — whatever you've got. Within a week — usually sooner — you'll hear which starting point you're at, which bracket the system falls into, and whether it's a job I'll take.