Process
Hired someone technical before and got burned?
Most automation horror stories share a shape: vague scope, silent progress, an undocumented handover, and a system only its builder can touch. My process is designed against each of those, specifically.
Scope — in your language, not mine
You describe the manual work in plain terms: "every Monday someone spends 3 hours matching X to Y." I write back what I understood, what I'd build, what it costs, and what I'd deliberately not build in version one. If automation isn't worth it yet, I say so — a small fix now beats a big invoice for shelf-ware.
Build in reviewable slices
You see working software the first week, not a status report. Each slice runs on your real data, and you can redirect me while redirecting is still cheap. No three-week silences followed by a big reveal.
Safety is built in, not bolted on
Anything customer-facing starts in draft mode — the system writes, a human approves — until it has earned trust. Jobs are idempotent (a crash and restart can't double-send an email or double-charge a card). Failures alert; they don't hide.
Documented like I might disappear
Every system ships with a README (what it is, how it works, its tradeoffs) and a runbook (how to restart it, where the logs live, how to tell it's healthy — written for a non-developer). My open-source repos show exactly what this looks like; the docs are the product too.
Handover, completely
Code in your repo, running on infrastructure you control, credentials in your hands. You are not a hostage: any competent developer could take over from my documentation. Ongoing support is available because it's convenient — never because it's required.
What working with me feels like
- Clear, frequent, written communication. Short async updates that say what happened, what's next, and what I need from you. No jargon unless you want it.
- Ownership. When something breaks — and in real systems something eventually does — I don't wait to be told. Monitoring tells me first, and you get "found it, fixed it, here's why" instead of silence.
- Honesty about limits. If a tool you already pay for solves it, I'll point at the tool. If my estimate was wrong, you hear it early, not at the invoice.
- US-hours overlap. I've worked with US teams for years and keep meaningful timezone overlap for standups, handoffs, and "can you look at this now?" moments.
Questions clients ask
What happens when something breaks at 3am?
The system notices before you do — health checks and alerting are part of every build, not an add-on. Jobs are designed to fail loudly and restart safely. And because everything ships with a runbook, "turn it off and on again" is a documented, safe operation anyone on your team can do.
Do we own the code?
Yes. Everything I build for you lands in your repository and runs on accounts you control. My open-source work is public precisely so you can verify how I build before you pay me anything.
Why code instead of Zapier-style tools?
Sometimes those tools are the right answer for simple glue — and I'll say so when they are. But past a certain complexity you're paying rent forever on something fragile that nobody can debug. Code is testable, versioned, portable, and yours.
How do you use AI without it making things up?
AI handles judgment calls with a safe fallback; deterministic code handles everything repeatable. Numbers always come from real queries — the AI is allowed to narrate, never to invent. And anything customer-facing gets human review until trust is earned.
Can you work with our existing stack?
Almost certainly — the job is meeting your systems where they are: CRMs, phone systems, spreadsheets, e-commerce platforms, accounting tools. If it has an API, an export, or a webhook, it can be automated.
Start with the smallest useful thing
The best first project is small, annoying, and measurable — a weekly report, a follow-up sequence, one integration. It proves the working relationship in weeks, not quarters. Then we scale what works.