Skip to content
How I work

No mystery, no retainer you can’t get out of.

Hiring a developer is mostly an exercise in trust, and trust is easier when the mechanics are boring and visible. Here's exactly how a project runs.

Fixed price, written down

Scope and cost agreed before anything is built, along with the monthly figure to keep it running. If scope changes, that's a conversation and a new number — not a surprise on an invoice.

Riskiest thing first

The integration nobody is sure is possible gets proven in week one, not month three. If it turns out it can't be done the way we hoped, you find out while it's still cheap to change course.

You own everything

Code, cloud accounts, data, documentation. Standard platforms, no proprietary runtime of mine. Handing the whole thing to another developer should be an afternoon, not a project.

Failures get written up

When something breaks in production it ends in a document: what happened, why, what changed so it can't repeat. I keep those for my own systems and I'll show you real ones.

How it works

Four steps, no mystery, no retainer you can't get out of.

You will always know what is being built, what it costs, and what happens if it breaks at 6pm on a Friday.

  1. A call, then a day of watching

    Week 0 — free

    Thirty minutes on the phone to work out whether this is even worth building. If it is, I spend real time watching how the work happens today — the spreadsheet, the group chat, the thing somebody retypes every Friday. Most of the value gets found here, not in the code.

  2. A written scope with a number on it

    Week 1

    What gets built, what explicitly does not, what it costs to build and what it costs to run every month. Fixed price. If I think the honest answer is "a spreadsheet and a rule", you get told that instead of a proposal.

  3. Something usable, early and often

    Weeks 2–6

    Small pieces in your hands quickly, so course corrections are cheap. The riskiest part gets built first — the integration nobody is sure is possible, the offline path, the bit that touches money. Never the easy screens first.

  4. Live, then watched

    Ongoing

    Go-live is the start of the job, not the end. Alerting on the paths that matter, a runbook for whoever is on the phone, and a written post-mortem for anything that breaks. You own the code and the accounts either way.

Questions

The things people ask before they trust a stranger with their operations.

If yours isn't here, ask it on the call — I'd rather answer it early.

One developer. I take a small number of clients at a time so each one gets real attention, and you always talk to the person writing the code — there is no account manager between us. Where extra hands genuinely help, I bring in people I've worked with before and I stay accountable for the result.

Tell me the thing your team retypes every week.

Thirty minutes, no pitch. I’ll tell you whether it’s worth automating, roughly what it would cost, and if the honest answer is “don’t bother” — you’ll hear that too.

Book a free callSend a message instead

hello@clearpathflow.io · Raleigh-Durham, NC