Case studies
What they arrived with. What they left with.
Four clients and two products of my own, written up the same way: the before, the after, and the one call that made the difference. I was architect and sole developer on all six.
Client systems run in the clients’ own accounts, so their figures are theirs to publish. The only numbers on this page are mine.
Version 16 is running.
- Built this week
- Slots learn from which ones get accepted and declined, both sides
- Still working from week 12
- Screenshot a WhatsApp thread, get the slots that fit
- If there is a week 17
- The day on a map, with travel time between meetings
Six systems
Before and after, in one line each.
Booking a meeting went from a chain of emails to one exchange.
Arrived with
Screen mockups and a wish list. The judgement that picks a meeting time — habits, travel, who outranks whom — lived in one assistant’s head.
Left with
A scheduler that learns each boss’s hours from the calendar, ranks slots for least travel and waiting, improves from which slots get accepted, and answers a WhatsApp screenshot with the slots that fit.
The call
The spec was a workflow: fixed steps. Scheduling isn’t; it’s a ranking. So the screens they arrived with were never built. A new version every week, tried by real users, replaced the plan.
For the engineer
Hard constraints filter, weighted preferences rank, accept/decline history adjusts the weights. The model reads requests and writes the explanation; it never picks the slot. Flask, one worker, PostgreSQL 16 for sessions, queue and storage. Every query scoped to a user_id by construction. Gmail read and compose only; no send scope, on purpose.
Schematic — shape only
Forty weeks, bought one at a time
Each square is a week they chose to buy, back when the unit was a week, and could have declined. Schematic — shape only
The only hard number it has
Schematic — shape only
Back to adding features with Codex, without breaking the rest.
Arrived with
A repo vibe-coded in Codex, deployed, serving nobody. One CRM hardwired, half the credentials in the code, half the features working — and nobody, Codex included, could say which half or why.
Left with
The same product as software. Any customer signs up and sets their own process. Any CRM plugs in. It keeps running when a CRM’s API doesn’t match its own docs — in German real estate, often.
The call
The problem wasn’t the code, it was the shape: business rules in a spreadsheet, a production system reading them and guessing from a log. Two queues and adapters replaced that — the one shape where a vibe-coding tool can add a feature without touching anything else.
For the engineer
Adapters normalise vendor events into one shape in and vendor calls out of one shape out, so the rules engine never knows which CRM it’s talking to and a bad API can’t reach it. Every event and action carries a tenant; rules are tenant data. Adapters are written against observed behaviour, not documentation, and tested in isolation.
Before — roughly half worked; nobody knew which half
Schematic — shape only
After — every feature through the same two queues
Schematic — shape only
Version 10 is running.
- Built this week
- Second CRM connected. One adapter, one prompt, contained and tested.
- Still working from week 6
- Tenants register and define their own process
- If there is a week 11
- Your call. The code and the accounts are yours already.
A two-day laptop run moved to the cloud, and one scientist’s tool now reaches all fifteen.
Arrived with
A well-built pipeline that only ran on laptops: a day or two per run, results visible to one person. Four scientists had vibe-coded the same graph browser without knowing it.
Left with
The pipeline in the cloud on compute that comes up for a run and shuts down after. One shared store, secured, team and user access kept apart. An API to the graph that answers what a claim rests on with the paper and page, or the memo, it came from, and a place to deploy their own tools.
The call
Don’t rewrite the pipeline. It was good; the problem was where it ran. Move it, build the platform around it, and make deploying a vibe-coded tool cheap enough that sharing beats rebuilding.
For the engineer
Same stages, now against an object store and a compute layer that scales to zero. State lives in the store, not on a machine, so a run can be inspected by someone who didn’t start it. A query API over the graph is what every tool reads; the scientists’ apps deploy beside it without an engineer in the loop.
Schematic — shape only
Where a run lives
Schematic — shape only
The same tool, built four times
Schematic — shape only
Volkswagen’s HR insights, made real time.
Here as proof of the other kind of client: not an idea or an MVP, but an established company with a working system, a precise ask, and no wish to hear about a rewrite.
Arrived with
A system that tracked who was opening which jobs, which skills were in demand and which were being replaced by AI — for Volkswagen’s HR department to plan with. It worked, and it was slow as hell: once a month a batch job ran over the postings, took a few days, and produced a handful of reports that HR read for the following month. A vacancy opened on 16 September reached a reader around 5 October.
Left with
The same data, real time. A posting opened today is in the database today. Many years of postings answer a query in a blink, and instead of reading a report the team asks a question in plain language: the AI writes the SQL, the query runs, the data comes back.
The call
Leave the collection alone; they hadn’t asked for it and it wasn’t the problem. The month between a posting and a reader was. Four separate changes that are easy to blur into one: latency, storage, access, interface. The reports went away entirely — they see the data first and query it after.
For the engineer
Postings land in an AWS data lake. A DAG runs over the lake: extract, convert, pull the required skills out of each posting, build the analytics on top — that is where the month went. The analytics now land in ClickHouse, which is what makes a query across the whole history fast rather than a run across it. A model turns a plain-language question into SQL against ClickHouse; the SQL executes; the answer is the rows, never the model’s memory.
FROM job_postings
WHERE opened >= toStartOfQuarter(today())
AND skill NOT IN (SELECT skill FROM job_postings
WHERE opened BETWEEN today() - 372 AND today() - 280)
GROUP BY skill ORDER BY postings DESC LIMIT 5
Before — a posting waits for the monthly run
Schematic — shape only
After — the data first, the question second
Schematic — shape only
A million pages a day, and nobody on duty.
Here as evidence the method builds real things, not as a client outcome. These are the only figures on this site I am free to publish.
Started with
Hundreds of career pages to read every day, and nobody to run the machine. At that size a system that needs an operator is a system that stops.
Runs as
Thirty-odd services, each with one job. Two things read the results — a filter console and a public site — and neither can ask an expensive question by accident.
The call
Nothing reaches the web on its own. One fetch service — real browsers on rented addresses — and everything else asks it for a page. One bill to read, one place to break, no service quietly growing its own crawler.
For the engineer
Sources go to the fetch pool, then a crawler normalises and dedupes, then classification into a store the API reads from. The company graph stores claims about companies, not companies. The filter console splits counting from searching into routes that cannot express each other. The mail service is in the picture because I run it, not because anything here uses it.
The pipeline, one job per service
Schematic — shape only
Eight programs, two wires, nothing sent.
Started with
Outreach is eight small jobs: collect the lead, find who holds the role, write the message, produce the CV, sync the profile, sort postings, run the funnel, keep the ledger.
Runs as
Eight programs, one per job. Only two are joined. Every step that spends money is gated before each charge. The AI picks which facts to cite, never the sentence.
The call
Shut down the role lookup: every answer was a paid people-search call and the economics ended it, not the engineering. And an honest one: nothing has been sent. Either the gates work as built, or they’re set so tight nothing gets through. I don’t claim to know which.
For the engineer
The CV generator seeds the outreach engine with stored facts; the engine hands the message to an outside sender behind one seam. That seed and a replaced route to the role lookup are the only two wires, and neither is a call at runtime. The other five touch no sibling, reaching outward only.
Eight programs, two wires
Schematic — shape only
The thing you want to sell is probably the next one.
That’s the claim worth testing on a call: that the method transfers, not just that these worked. Twenty minutes with the engineer who did all six, and you leave knowing what I’d build first, what’s hardest, and what I’d talk you out of.
Book the twenty-minute callEngineer this got forwarded to? Start at how it runs.
