4 problems, no clients named
Work
Four problems from recent engagements, written up with the reasoning intact: what the constraint actually was, where the obvious approach broke, and what got built instead.
Past work is the most honest description of what I can do for someone else, so here are four problems from recent engagements: what the constraint actually was, where the obvious approach broke, and what got built instead.
The engagements are under NDA, so no client, product or market is named. Everything that matters survives that — the reasoning, the decisions, and what each one turned out to generalise to. No figures appear here that I cannot stand behind.
An AI-written rule engine that still answers deterministically
Eligibility across four dimensions, with far too many combinations to write a case for each — solved by moving the language model out of the request path and having it produce storable rules instead of verdicts.
- PayloadCMS
- TypeScript
- zod
- OpenAI
- REST
A CSV import built for a few million rows
Import and export between CSV files and PayloadCMS collections at millions of records, where reading the file into memory is not a slow version of the right approach but a different one that stops working.
- PayloadCMS
- TypeScript
- Node streams
- CSV
Protocol plumbing, implemented once and versioned
Webhooks and OAuth2 client credentials shared across more than one PayloadCMS application, where the engineering that mattered was the release discipline rather than the code.
- PayloadCMS
- TypeScript
- OAuth2
- Webhooks
- semver
Shipping while the requirements kept moving
A legal-agreements platform built against unclear and shifting requirements, inside an ecosystem of older systems that could not be changed — where planning for the uncertainty beat trying to eliminate it.
- PayloadCMS
- TypeScript
- Kubernetes
Have a problem that looks like one of these?
Describe what you are building and where it currently hurts. A straight answer follows — including when I am not the right fit.