the trust page

How I work

Cheap and fast is easy to claim. What follows is the mechanism that makes it true, and the terms that protect you when it isn't.

Specification before price

Nothing gets a fixed price until the scope is written down and signed. For smaller work that's a scoping conversation and a scope document. For anything substantial it's a paid specification engagement producing architecture, data model, interface contracts, infrastructure plan and a risk register.

The specification is yours regardless of what you do next. Take it to another vendor and you'll have a better brief than you'd have written yourself — and I've been paid for the work rather than pricing it into a bid I might lose.

Fixed price, fixed date, milestone payments

1specification
paid on delivery

2commencement
% on signature

3milestones
invoiced on sign-off

4final delivery
balance on acceptance

You're never more than one milestone ahead of delivered, accepted, testable work. If you stop the engagement, you owe what's been accepted — not the rest of the contract.

Change requests are priced, not absorbed

Requirements gaps surface on any non-trivial build. When they do, the change is scoped, priced and approved in writing before it's built. The alternative — absorbing changes silently until quality quietly becomes the thing that gives — is what this prevents.

Your code, your repository, from day one

Development happens in your repository, in your organisation. You see every commit as it lands. No staged reveal, no handover event where you find out what you actually bought.

Production credentials and deployment keys transfer on final payment. You can see and test everything throughout; the live switch flips when the invoice clears. That's the only leverage a solo engineer has, and I'd rather state it plainly than pretend it isn't there.

The single-engineer question

You should ask it, so here's the answer before you do.

faq.logread-only

              // availability
              I hold a defined weekly capacity for one engagement at a time. No parallel builds — your project doesn't queue behind someone else's.
               
              // continuity
              All work lives in your repository, all infrastructure is defined in code. If I disappear tomorrow, another competent engineer picks up a documented, reproducible system — not a black box. Deliberate design choice, not a happy accident.
               
              // communication
              A fixed weekly demo, written updates at each milestone, a defined response window for anything urgent — stated in the contract.
               
              // larger work
              For engagements beyond what one person should carry, I'll say so and either scope it down or decline it. I'd rather lose the contract than miss the date.
            

After delivery

Delivery includes a defined hand-over: documentation, a walkthrough with your team or your next vendor, and a support window for defects against the signed specification.

After that I step away. If you want me back for further work, we scope and price it then. I don't sell retainers or open-ended managed support — you shouldn't be paying a monthly fee for availability you may not need, and I won't sell something I'd have to under-deliver.

See it applied to a real engagement

$ read-case-study $ talk-to-me