Systems that run, not demos that impress.
Production AI and data systems for consumer goods, biotechnology and software. I learn how the work actually gets done before deciding what to build, which is why these systems get used rather than admired.
- Systems in production across three industries
- Deployed on Azure, AWS and Vercel
- Running unattended since 2025
Work
Three industries, three problems worth solving
Each of these started the same way: someone doing the same work by hand every week, or not doing it at all because there was no time. Client names withheld.
Market intelligence and field sales enablement
A pipeline joining several external supplier feeds to the client's ERP, publishing a reliable weekly picture of competitive position across a large retail network that was previously assembled by hand, if it was assembled at all.
Built on top of that, a workflow that reads the computed opportunity set, works out the single location and product worth a visit, writes a specific ask the field rep can use at the counter, checks every figure in that sentence against its source before release, sends it to his phone, and records what he did with it. The model writes language. Every judgment sits in code, where it stays auditable afterwards.
Research platform for a device startup
Study management on a modern web stack, taking in device telemetry, handling documents and supporting protocol drafting with AI assistance. Built for a small team that needed the platform to work before it needed it to be clever.
Systems that were never meant to speak to each other
Order, inventory and production data connected across platforms with no shared vocabulary and no intention of acquiring one, then turned into something an operator will actually open on a Monday morning.
Capability
What I build
Four things, in roughly the order businesses ask for them.
Knowledge and retrieval systems
Making what an organisation knows searchable, rather than dependent on whoever happens to be available that week. Retrieval architecture, embeddings, metadata design, and the governance that stops a system asserting something the business cannot stand behind.
Agentic workflows
Systems that read a computed state, decide the single action most worth taking, put it in language someone can act on immediately, and record what happened. Deployed to whatever the person already opens, which is rarely another application.
Data pipelines and integration
Joining systems of record to external feeds on a schedule, with verification at each step and an exit code when something is wrong. Unglamorous, and usually the reason the interesting work becomes possible.
Document and report generation
Turning analytic output into material a person can read, under constraints that keep the generated version honest about what the underlying data supports.
Approach
How I work
Deployed beats designed
A modest system running unattended every week is worth more than an architecture nobody adopts. I scope for what can be shipped and checked, not for what demonstrates well.
Code decides what is true
The model handles language and nothing else. Give a model room to produce a figure and it eventually produces the wrong one, and that cost lands on you rather than on me.
Governance is not a later phase
Twenty years of balance sheet risk teaches you that the exposure you failed to model is the one that finds you. Validation, provenance, audit trails and data residency go in at the start, because retrofitting them is how projects stall.
Embedded, not at arm's length
I work alongside the people who do the job, because the useful detail is never in the brief. One workflow, one real problem, running before we discuss the next.
Stack
What it runs on
Chosen for being well understood rather than for being new. Nothing here is an experiment at a client's expense.
Models
- Anthropic Claude (API)
- Claude on AWS Bedrock
- Azure OpenAI
- Cohere embeddings
Application
- Next.js / React
- Node
- Python
- TypeScript
Data
- PostgreSQL / Supabase
- DuckDB over Parquet
- FAISS
- Odoo, SFTP, EDI
Run
- Vercel
- Azure App Service
- Azure Container Apps
- n8n, GitHub Actions
Fit
Whether this is worth a conversation
Being clear about the second column saves us both a call.
Likely a fit
- Someone makes the same decision repeatedly with incomplete information
- What the business knows lives in documents and in people's heads
- Two systems hold data that has never been joined
- You want to see something running before committing further
- You are sceptical of AI claims but open to a specific one
Probably not
- You want a strategy document rather than a working system
- The work needs a team of engineers rather than one builder
- You are looking for research rather than production
- Success has not been defined and nobody wants to define it
Contact
Tell me what keeps going wrong
The most useful first conversation is about a problem, not about AI. If there is something worth building I will say so, and if there isn't I will say that instead.