The demo worked. Now it has to work on a Tuesday.
Getting an LLM to do something impressive once is a weekend. Getting it to do the same thing reliably, for real users, with someone accountable when it is wrong, is the actual job. I build that part.
| Signal | Severity | Usually means |
|---|---|---|
| Demo works, production does not | High | No eval harness |
| Prompt changes break things silently | High | Nothing is measured |
| Retrieval returns plausible nonsense | Moderate | Chunking or ranking |
| Agent loops until the bill arrives | High | No termination logic |
| Nobody owns it after the hackathon | Unknown | No owner, no roadmap |
Why the last ten percent takes the other ninety
A prototype has one user who knows what to type. Production has thousands who do not, and a handful actively probing what the thing will say. The gap between those is where most AI projects quietly stall.
The hard parts are rarely the model. They are: knowing whether a change made things better or worse, deciding what happens when the model is confidently wrong, keeping a human in the loop without making the feature useless, and stopping a long-running agent that has lost the plot.
All four are engineering problems with known shapes. None of them are solved by a better prompt.
What I actually do
- Build agentic systems with real termination conditions, durable workflows that survive a restart, and approval gates on the actions that matter
- Build RAG pipelines where retrieval is debuggable — you can see what was retrieved, why it ranked, and what the model did with it
- Build MCP servers that expose your platform to agents and outside developers with permissions that are actually scoped
- Set up evals so a prompt change produces a number, not a vibe
- Wire in confidence scoring and escalation, so the system knows when to hand over to a person
What you end up with
- A working feature in your codebase, in your style, that your team can maintain after I leave
- An eval suite that runs in CI and fails when quality drops
- Observability on the parts that matter: token spend, latency, escalation rate, tool-call failures
- Documentation aimed at the engineer who picks this up in six months
How the work runs
| Stage | What happens |
|---|---|
| Weeks 1 to 2 | Scope: what the feature must do, what it must never do, and how we will know it works. |
| Weeks 3 to 8 | Build, in your repo, with your review process. You see progress weekly. |
| Weeks 9 to 12 | Harden: evals, observability, failure handling, and the handover. |
| After | I stay reachable while your team takes it over. No cliff edge. |
Questions people ask
Do you write the code or specify it?
I write it. In your repository, through your review process, in the style of the code already there.
Which stack?
Go and Python for services, TypeScript where the frontend needs it. AWS Bedrock or direct provider APIs for models. I will use what you already run rather than importing my preferences.
Can you work with our existing team?
That is the usual arrangement. I am in your standups and your pull requests, and the point is that your engineers can maintain it afterwards.
What if we are not sure what to build yet?
Then the first two weeks are worth more than the rest. Scoping an AI feature honestly — including deciding not to build it — saves more money than any implementation choice.