AI Tooling & Developer Infrastructure

The unglamorous layer that makes AI systems usable: credentials, pipelines, CLIs, and services agents can actually call.

Most AI projects stall on plumbing rather than intelligence. The model works in a notebook and then dies on the way to production, because nothing in the surrounding system was built for a non-human caller: credentials assume a person at a keyboard, APIs assume a browser session, and failures assume someone is watching. I build that surrounding layer — the tools, services, and interfaces that make AI systems operable by both agents and the humans responsible for them.

What I build

Agent-facing APIs and services

Services designed for a caller that has no browser, no email inbox, and no ability to complete a signup flow. That means machine-issuable credentials, predictable failure semantics, idempotency where retries are likely, and error messages a model can act on. cron402 took this to its conclusion: an agent's wallet is the only credential it needs, with no account at all.

MCP servers

Model Context Protocol servers that expose your internal systems to AI clients with the right granularity. The hard part is rarely the protocol — it is deciding what to expose, how to shape it so a model uses it correctly, and how to make the boundary safe enough to leave running.

Secrets and credential infrastructure

Getting API keys to automated systems without a human pasting them into a chat window. I have shipped this as a product: a biometric-gated local vault with a loopback API, scoped and expiring keys, an MCP interface, and a subprocess wrapper that injects environment variables without ever writing them to disk.

Self-hosted inference pipelines

When private code or customer data cannot go to a hosted provider, the work runs locally. I build Ollama-backed pipelines with staged generation, so output is derived through structured intermediate steps rather than one enormous prompt — which is both more reliable and far easier to debug when a stage goes wrong.

Developer CLIs and distribution

Command-line tools people will actually install, with a working cross-platform story, a doctor command that diagnoses the environment before anything fails mysteriously, and a self-update path. I have published this to npm and maintained it across macOS, Linux, and Windows.

How I work

The first question is always whether the tool should exist. A surprising amount of AI tooling work is better solved by deleting a step than by automating it, and I would rather tell you that in the consult than bill for building it.

I build the smallest thing that runs end to end first, then harden it. For tooling this matters more than usual, because a developer tool's real requirements only become visible once someone tries to install it on a machine you did not configure.

Cross-platform behaviour and failure messages get treated as features, not polish. A tool that fails with a clear explanation on Windows is more valuable than one that works perfectly on your laptop only.

Everything ships with the installation path documented and verified from a clean machine, because the difference between a tool that gets adopted and one that gets abandoned is almost always the first five minutes.

Proof

Case studies from work I have built and run, not client logos.

Stack

  • TypeScript
  • Node.js
  • MCP
  • Ollama
  • Cloudflare
  • Docker
  • Postgres
  • GraphQL
  • REST API

Questions

Do you build MCP servers for existing internal systems?

Yes — that is one of the most common and highest-value pieces of this work. The engineering effort is in the boundary design: which operations to expose, how to shape them so a model calls them correctly, and how to make the destructive ones safe. The protocol itself is the easy part.

Can you work with our existing secrets manager?

Yes. I have built a vault from scratch, but that does not mean replacing yours. If you already run Vault, AWS Secrets Manager, 1Password, or Doppler, the work is building the agent-facing access layer on top of it — scoped, expiring, auditable, and with no human in the retrieval path.

Can inference run entirely on our own hardware?

Yes. I run self-hosted Ollama in production for exactly this reason — private repositories should not be sent to a third-party model. Local inference has real trade-offs in capability, so I will be straightforward about which parts of a pipeline genuinely need a frontier model and which do not.

Do you publish and maintain packages, or just hand over a repository?

Either. I have published and maintained tooling on npm with cross-platform installs, a self-update path, and release manifests. If you want the package published under your organisation with a maintenance handover, that is a normal part of the engagement.

What is an MCP server?

An MCP server exposes a set of tools to an AI client over the Model Context Protocol, so a model can call your systems directly rather than having capabilities hard-coded into one application. In practice it is an adapter: it declares what operations exist, what arguments they take, and what they return. The protocol is straightforward — the engineering work is deciding which operations to expose, shaping them so a model uses them correctly, and making the destructive ones safe enough to leave running unattended.

How do engagements start?

With a paid 30-minute consult. Bring the actual problem — I will tell you whether it needs building, and roughly what it costs if it does.

Last updated .