how-i-work › the money side
How I take your money
How-i-work covers the mechanism. This is the money side of it: what a build costs, how that number is arrived at, and the terms that hold from the first invoice to the last. No ranges, no day rates, no "contact us for pricing".
what you're buying
One price. One date. Both in writing before you commit.
A working system on AWS: designed, built, deployed, handed over. Not a team on loan, not a retainer, not a discovery phase that bills you while it decides what to do.
The price is fixed and the date is fixed, paid in milestones against work you've accepted rather than hours billed as they accrue. Requirements gaps turn up on any non-trivial build. When they do, the change is scoped, priced and approved in writing before it's built, instead of absorbed quietly until quality is what gives.
start
before you commit
same document
That figure is a threshold rather than a price: below it, the specification, the benchmarking and the written commitment cost more than they save, for both of us.
how the number gets set
Priced against what this costs you elsewhere
Every build price starts from the same question: what would this scope cost you from a competent team? If you're holding a quote, that question is already answered. Send a written, fixed-price quote from a named vendor for a scope I can match, and you'll get a straight answer inside a week, usually much sooner, at no cost either way. The pattern so far: around half the price, and up to half the elapsed time, once the coordination overhead comes out.
No quote? Then I build the benchmark myself. I size the work, price it the way the market would, and set my number against that.
Not a promise. Some quotes are already keen, and some work genuinely needs more than one pair of hands. When either is true, that's what you'll hear.
what has to happen first
The clock starts when the spec is signed
A price that holds needs something to hold on to: architecture, data model, interface contracts, infrastructure plan, risk register. Written down, with my name on the result. That signature is what makes the number binding, which is why it has to be mine.
I'd rather build your system than write about it, so the less of that document I have to author, the sooner you're looking at a price and a date. Three ways this usually goes.
You already have one.
The engagement is verification rather than authorship. I read it, close the gaps, sign it. Cheapest route in, shortest route to a build date, and the one I'd rather you took.
You have part of one.
We close the rest up front, on a fixed top-up agreed at intake. Days added to the front of the schedule, not weeks.
You have none.
It gets written from scratch before anything can be priced. Longest path to a start date, and the most expensive one.
Producing that document is a paid engagement in its own right: a fixed fee set by the size of the system, USD 2,500 for a smaller scope and USD 5,500 for a substantial one, with 50% credited against the build if you build with me. It's yours either way, and what each bracket buys is set out in full on the-spec.
The build price isn't published alongside those, because it doesn't exist until the spec is signed. That's the sequence above doing its job.
the terms, everywhere
What's true regardless of route
Payable on commencement.
The spec fee is due when that work starts. Build payments follow the milestone schedule in how-i-work.
Anchored in USD.
Every price is set in USD and changes only by a deliberate pricing decision. The other currencies are converted from that anchor and refreshed each quarter, so the figure you see can move a little while the price itself hasn't.
Invoiced in USD, GBP, EUR or ZAR.
Whichever you need, agreed up front, before the first invoice, rather than decided invoice by invoice.
next
Send me what you've already got
A competitor's quote, a spec, a half-finished brief, or the system described in an email. Any of those is enough to get a number back.