It depends enough on your systems that a published price list would be misleading. Two storefronts with clean, documented APIs is a very different job from a legacy ERP nobody has notes for, even when the brief sounds identical. After a twenty minute call I send one fixed figure against a written scope, usually within three days, and it does not move unless the scope does. If your budget is the constraint, say the number up front and I will tell you honestly whether it is enough.
THREE WAYSTO HIRE ME.
Every project is quoted after a short scoping call, because the honest number depends on your systems rather than on a price list. What you get is one fixed figure against a written scope, and it does not move unless the scope does.
AI agent
build
A voice or chat agent, or an MCP server that gives one safe access to your systems. Taken from idea or prototype to something that survives production.
- 4 to 8 weeks
- Quoted after scoping
- 3 milestones
- A working agent deployed on your infrastructure
- Telephony or chat surface wired up, Twilio and Retell AI where voice is involved
- MCP servers exposing your tools with scoped permissions
- Transcript and outcome capture written back to your CRM or database
- Fallbacks for provider outages, timeouts and refusals
- Prompt and behaviour documentation your team can edit
- 30 days of post launch support
- A prototype works in a notebook and now needs real users
- A repetitive conversation eats a team's day, inbound or outbound
- You want agents acting on internal systems without hand written glue
- An existing AI feature is unreliable and nobody knows why
Integration
& automation
Two or more systems that need to talk, or one expensive manual process that needs to stop being manual.
- 3 to 6 weeks
- Quoted after scoping
- 2 to 3 milestones
- A working integration deployed to your infrastructure
- Webhook or scheduled sync, whichever suits the data
- Retry, backoff and a dead letter path for failures
- An exception view so your team can triage without me
- Written architecture and runbook documentation
- 30 days of post launch support
- Someone is copying data between two systems daily
- Stock, pricing or orders disagree across channels
- Reports are assembled by hand on a schedule
- An existing integration breaks often enough to hurt
Engineering
retainer
Standing capacity for teams that need backend or AI work continuously but not a full time hire.
- Monthly, rolling
- Quoted after scoping
- 30 days, either side
- An agreed block of days each month, planned with you
- New endpoints, jobs, dashboards, agents and integrations
- Maintenance on anything I have already built for you
- A named person to call when something breaks
- A short written summary of what shipped each month
- Frontend is covered but backend work keeps queueing up
- You have agents or integrations running that need someone watching
- Hiring is months away and the roadmap cannot wait
- You are an agency needing backend and AI depth per project
Included in
every engagement
Your code, your repo
Everything ships to your repository and your infrastructure. No wrapper, no lock in, no dependency on me.
Documentation
Architecture notes and a runbook written for the next engineer, not as a formality.
Weekly demos
Staging you can click through every week. You always know what state the work is in.
30 days support
If something I wrote misbehaves after launch, I fix it. No hourly clock, no argument.
The process, in detail
Map the process
A twenty minute call where you walk me through the work as it happens today. I am listening for how often it runs, who does it, how long it takes and what goes wrong when it is skipped.
You leave that call with an honest read on whether this is worth building. Sometimes it is not. A process that runs twice a month rarely justifies the spend, and I will say so rather than sell you one.
Scope in writing
You get a short document: what gets built, what explicitly does not, the fixed price, the milestones and the delivery date. The exclusions list matters more than the inclusions, because it is where projects usually go wrong.
Nothing starts until you have approved it. If you want to change scope later, that is fine. It becomes a written change with its own price, rather than a quiet argument at the end.
Build in the open
Work lands on a staging environment continuously, and once a week we look at it together. Fifteen minutes, screen shared, showing what moved.
Anything risky goes behind a read only mode first, where the system logs what it would have done so we can check it against reality before it is allowed to write. That is how the catalogue sync was rolled out without downtime.
Hand over properly
Deployed to your infrastructure, documented, with alerting wired to wherever your team already looks. We walk through the runbook together so somebody on your side can operate it.
Then thirty days where I am on hand for anything that surfaces. Most systems reveal their real edge cases in the first fortnight of live traffic, and that period is included rather than billed.
What I
don’t do
Being clear about this saves us both a call. If you need one of these, I would rather point you elsewhere than do it badly.
Model training
I integrate and deploy models, and I build the systems around them. Training or fine tuning your own is a different specialism.
Brand & visual design
I build interfaces to a design, and I build functional internal tools. Identity and marketing design is not my discipline.
Mobile apps
I will build and document the API your app consumes. Native iOS and Android work is somebody else's job.
WordPress & page builders
Theme and plugin work is not what I am good at or interested in, even though it happens to be PHP.
Money &
terms
Start with the
cheapest step.
Twenty minutes, no pitch, no obligation. If building it will not pay for itself, you will hear that on the call.