Approach

The same four steps on every project, so you know where things stand at each stage.

  1. 1 Build
  2. 2 Evaluate
  3. 3 Deploy
  4. 4 Monitor

1

Build

We start with your problem, and I turn it into an agent or retrieval pipeline with solid engineering underneath.

I’ve been a backend engineer since 2012, long before AI arrived: APIs, databases, background jobs, and WordPress plugins running on live sites. I bring that same discipline to AI. A system I build for you isn’t a prompt wrapped in a script: it has clear data models, defined workflows, careful error handling, and limits on what the model is allowed to do. LangGraph and LlamaIndex are the tools I usually reach for; the engineering around them is what makes the system dependable.

2

Evaluate

Checking that it works on your data before your team relies on it.

I’ve always worked test-first, and AI needs that care even more, because a model can sound confident and still be wrong. Before anything goes live, I build a test set from your real documents and questions, and measure accuracy, retrieval quality, and where it falls short, so you can see how it performs before deciding. On Atlas Planner, benchmarking was how we chose between approaches, using numbers rather than guesses. Later changes are checked against the same tests, so an improvement in one place doesn’t quietly break something else.

3

Deploy

Getting it running reliably, wherever your data needs to live.

I’ve been shipping software to production for over a decade, from releasing WordPress plugins through SVN to deploying sites through CI/CD pipelines. I bring the same habits to AI: versioned releases, automated deployments, and a clear way to roll back. If your data can’t leave your own servers, I can run open-weight models on your machines through Ollama or vLLM behind a private gateway, or put a privacy layer in front of cloud models.

4

Monitor

Looking after it once real people start using it.

AI systems rarely crash. Instead they drift: answers slowly get worse, costs creep up, responses slow down. So I set up tracing for every request, so any answer can be followed back step by step, along with dashboards for quality, cost, and latency, and alerts when something moves out of range. Spending has hard budgets, and there’s a way to switch the model off if needed. Years of running production websites taught me that a system needs looking after once it’s live, not just until launch.

How I use AI to build

I use AI tools to work faster at each step, with clear limits. I don’t put client names, personal data, or credentials into them, and if your contract rules out AI for certain steps, I do those by hand and use it only where it’s allowed.

  1. 1

    Design

    We agree on requirements and architecture before any code is written.

    • Architecture
    • ERD
    • Spec
  2. 2

    Plan

    Your reviewed spec becomes small, testable modules, each with its own plan.

    • Module plan
  3. 3

    Build & Review

    Each module gets its own branch and tests, and I review each change before it’s merged.

    • Branch
    • Tests
    • Review
  4. 4

    Ship

    Releases go through GitHub Actions to staging, then production, with a way to roll back.

    • CI/CD
    • Release

AI makes me faster. The judgement calls, and the responsibility, stay with me.