AI implementation · Granada / Remote

Hands-on AI implementation

You already know what you want to build. This phase is writing it to production standard: integrated into your stack, with tests, automated evals, observability and cost under control. I start from how we will measure that it works and finish with an operation your team can sustain without me.

This is the service for when the decision is already made — because we came from the design phase, because a pilot proved the idea works, or simply because you are clear about it — and it needs building properly. I join your repository, your CI and your code reviews, and work with the conventions you already have.

The distance between a demo and a production system is measured in the things the demo does not do: handling a provider error at three in the morning, not burning a month of budget in an afternoon, answering in under two seconds, versioning prompts so you know what changed when quality drops, and having a test that catches it before a user does. That distance is most of the work, and it is exactly the part that almost never gets budgeted.

  • A good fit if you know what to build and need someone to write it to the same standard as the rest of your code.
  • A good fit if your team knows product and backend but this is the first time an LLM sits on a user's critical path.
  • A good fit if you have a prototype that works in a notebook and it has to become a service someone can operate and maintain.
  • A good fit if you need temporary reinforcement with judgement: I come in, we build it, we document it and your team keeps it.
  • Not a fit if it is still unclear what problem the system solves or how you will measure whether it works. Building from there gets expensive — that is what the design phase is for.
  • Not a fit if you need a whole team across several fronts at once: I work alone, and that limits the bandwidth to one focused project.
Development inside your stack

Inside your application if it is Rails or Python, or as a standalone service behind an API if your stack is something else. With your conventions, your code style and pull requests someone on your team can genuinely review.

Automated eval suite

A set of cases with expected outcomes that runs on every change of prompt, model or parameter. Without it, tuning a prompt is a bet; with it, it is a change with a number before and a number after.

Tests and CI

Unit and integration tests with model calls stubbed, so the suite stays fast and deterministic, plus a separate layer of tests against the real provider. All inside your pipeline.

Observability

Traces of every operation with its prompt, response and latency; cost per operation; alerts when quality or spend drift out of range. When something breaks, you will know which step broke and with what input.

Cost and latency control

Caching where it makes sense, the small model for tasks that do not need the large one, per-user limits and streaming responses. Cost is an architectural decision and it gets made while building.

Deployment and documented handover

Deployment, operating documentation and a handover session with your team: how to change a prompt, how to add a case to the evals, what to look at when something goes wrong. Being able to carry on without me is part of the job.

In a production AI system, the model call is the small part. The expensive part is queues, retries, idempotency, permissions and spend control: ordinary backend engineering with one new source of uncertainty on top, and that is where my ten-plus years building APIs and systems at scale come in. In practice it comes down to three things I bring to every project. Prompts live versioned in the repository like any other code, with their history and their review. The eval suite runs in GitHub Actions on every pull request, so a change that degrades quality shows up before it is merged. And traces, latency and cost per operation are instrumented on the first deploy, before anyone needs them.

Ruby on RailsPythonFastAPIClaude APIOpenAI APIPostgreSQLpgvectorDockerGitHub ActionsEvals
01
Technical kickoff

Access, environment, reading the existing code, and agreement on scope, acceptance criteria and what "done" means in this project. One week, usually limited by access approvals rather than by the work.

02
Iterative build

Short cycles with something deployable in each one and a demo every week. Evals get written alongside the code rather than at the end. The range is wide on purpose: four weeks for a bounded feature, ten or more when several integrations are involved.

03
Hardening

Load, provider outages, edge cases, latency, budget and alerts. This is where it is decided whether the system survives a Monday morning. Two to three weeks before opening it to everyone.

04
Handover and support

Documentation, a handover session and an agreed support period for the first weeks in production. After that your team owns the system; I stay available if something comes up that needs the original context.

Tell me about your case and I'll tell you honestly whether AI is the right tool — and how I would implement it.