the commercial terms

How I work

Fast and well-built is easy to claim. What follows is the mechanism that makes it true, and the terms that protect you when it isn't.

Scope before price

Nothing gets a fixed price until what's being built is written down and signed — the system design, the data model, the interfaces, the infrastructure and the risks. For smaller work that's a scoping conversation and a scope document. For anything substantial it's a proper piece of work in its own right.

That definition 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.

Fixed price, fixed date, milestone payments

1scope agreed
and signed

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, your account

Development happens in your repository, in your organisation, deploying into your AWS accounts. 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.
            

Remote by design

I work remotely, asynchronously, against a signed scope — with a weekly demo scheduled inside your business hours and everything of consequence in writing. My working day overlaps the full UK and European business day and US East Coast mornings.

Invoicing in your currency, agreed up front. Contracts state deliverables, acceptance criteria and payment terms explicitly, so distance never has to be covered by trust alone.

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 scope.

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.

Understand how the work actually gets done

$ read-the-method $ talk-to-me