How a project runs
A free scoping call, a written spec with a fixed price, a build you watch in dry-run every week, and a handover into your own repositories with documentation and a runbook.
Fixed price means the number doesn’t move once we’ve agreed the spec. If the spec changes, we write down the change and the new number before anyone builds it. First projects start at $3,000.
Step 1
You get: A yes, a no, or a smaller first project.
Scoping call
Thirty minutes, free. You describe the process: what it is, who does it, how often, what goes wrong when it's late. I ask about the systems it touches and what documentation exists.
Sometimes the answer is that it isn't worth automating yet, or that writing the documentation is the better first project. I say so on the call.
Step 2
You get: A spec you can hold me to, and a price that doesn't move.
Written spec and fixed price
A short document: what the system will do, which systems it reads and writes, what it will not do, how we'll know it works, and what it costs. You review it. We change it until it's right.
Step 3
You get: A working system you've watched rehearse.
Build, with weekly dry-run demos
Every system I build has a dry-run mode from the first week. Each demo shows the real system running against real data and writing nothing. You see every action it would take before it's allowed to take it.
Integrations go live one at a time, each behind its own flag.
Step 4
You get: A repo, a runbook, and a system your team can run without me.
Handover
The code lands in your repositories and runs in your cloud accounts. You get documentation, a runbook for when it misbehaves, and a walkthrough with whoever will own it.
After that, ongoing tuning is an optional retainer. Many systems don't need one.
What handover includes
- The code, in your GitHub or GitLab organisation, with history
- Deployed in your cloud accounts: Vercel, Cloudflare, AWS, or wherever you already are
- A README that gets a new engineer running locally in under an hour
- A runbook: what to check when it misbehaves, how to turn each integration off, who to call
- The dry-run console, so your team can rehearse changes before shipping them
- A recorded walkthrough with whoever will own it
After handover
Ongoing tuning is an optional retainer from $600a month. It covers monitoring, model and dependency updates, and small changes. Many systems don’t need one; the runbook is written so that yours might not.
Fixes for anything that doesn’t match the spec are included, for as long as the spec is the spec.
Taking new projects · start within 2 weeks
Step one is a thirty-minute call.
What it is, who does it, how often, and what goes wrong when it’s late. I reply within one working daywith a scoping call or an honest reason it isn’t worth automating.