Product and platform engineering

The application around the model: interface, data model, auth, pipelines, infrastructure as code and a deployment your team can run.

Most of an AI product is not AI. It is a schema, an authentication story, an admin view, a background worker, a migration and a deploy pipeline. That work decides whether anyone can use the thing, and it is where projects that demo well quietly die. We build it as ordinary, careful product engineering, on your infrastructure, with your team able to run it without us.

What we actually do

Typed end to end: schemas in the database, at the API boundary and in the client, so a shape change is a compile error rather than a production incident
Interfaces designed for the review and correction workflow, because a human is in the loop on almost every system worth building
Background processing for anything that cannot answer inside a request, with retries, dead letters and visible queue depth
Infrastructure as code from the first deploy, in your cloud account, with environments that match
Migrations that run forward and back, tested, because the second release is where the risk lives
Continuous integration with tests, type checks, linting and the evaluation gate on the same pipeline
Accessibility and performance treated as build requirements rather than a later pass
Documentation and runbooks written during the build, as a condition of done

What we instrument

Measurements, not results. These are the readouts we put in place so that you end up with numbers about your own system. There are no values on this page because a value here would be somebody else’s.

Deployment frequency and change failure rate
Time from merge to production
Queue depth and job failure rate for background work
Error budget and uptime for the application surface
Test and type coverage on the paths that carry money or personal data

Where this stops working

We build web applications. Native mobile is possible in a longer engagement and is not what a six week sprint delivers
We work in the cloud accounts our clients already have. A platform migration is a separate piece of work with its own plan
If your existing data layer cannot support the feature, we will scope fixing it separately rather than building on top of it and calling it done

What we work with

Named as plain text. None of these is a partnership, an endorsement or a default: the right one is chosen per engagement, usually the one your team already runs.

TypeScript, Next.js and React
Python and FastAPI
PostgreSQL, including pgvector
AWS, Azure and Google Cloud, with infrastructure as code
GitHub Actions and comparable CI

engineering / the other five

None of these works alone.

C1Retrieval and contextGetting the right passages in front of the model. Most quality problems that look like reasoning problems are retrieval problems.C2Evaluation and quality gatesA labelled set, a threshold agreed in writing, and a gate in CI. Built before the feature, not after the first complaint.C3Agent orchestrationExplicit state, typed tools, bounded loops and a replayable trace. An agent is a distributed system, so we build it like one.C4Guardrails and escalationWhat the system may do alone, what it must hand to a person, and what the person receives when it does.C5Observability, cost and driftQuality, latency and cost per task on a dashboard your team owns, with an alert when any of the three moves.

Where does your system sit against this?

Send the architecture and the failure you are seeing. You get a written read from an engineer within a working day.

Start a build

What we actually do

Typed end to end: schemas in the database, at the API boundary and in the client, so a shape change is a compile error rather than a production incident

Interfaces designed for the review and correction workflow, because a human is in the loop on almost every system worth building

Background processing for anything that cannot answer inside a request, with retries, dead letters and visible queue depth

Infrastructure as code from the first deploy, in your cloud account, with environments that match

Migrations that run forward and back, tested, because the second release is where the risk lives

Continuous integration with tests, type checks, linting and the evaluation gate on the same pipeline

Accessibility and performance treated as build requirements rather than a later pass

Documentation and runbooks written during the build, as a condition of done

What we instrument

Deployment frequency and change failure rate

Time from merge to production

Queue depth and job failure rate for background work

Error budget and uptime for the application surface

Test and type coverage on the paths that carry money or personal data

Where this stops working

We build web applications. Native mobile is possible in a longer engagement and is not what a six week sprint delivers

We work in the cloud accounts our clients already have. A platform migration is a separate piece of work with its own plan

If your existing data layer cannot support the feature, we will scope fixing it separately rather than building on top of it and calling it done

What we work with

Named as plain text. None of these is a partnership, an endorsement or a default: the right one is chosen per engagement, usually the one your team already runs.

TypeScript, Next.js and React

Python and FastAPI

PostgreSQL, including pgvector

AWS, Azure and Google Cloud, with infrastructure as code

GitHub Actions and comparable CI