AI OPERATIONS
I run the P&L and build the systems that run it.
Decisions used to wait on data, and data waited on someone else's roadmap. That broke in 2025. One operator who can build now closes the loop instead of writing a spec and waiting two quarters.
WHAT GOT SHIPPED
Dashboards are cheap. A dashboard wired straight to the systems that charge the customer, built in the gaps of a full-time GM job, is not.
Ninety days at Relay Commerce. Three products, $2.6M ARR, one repo, no engineering headcount.
| Live KPI dashboard | 844 commits since May 2026 · 38 pages · ~70K lines · 177 migrations |
| Data pipeline underneath | ~20 sync jobs · ~30 Postgres tables · 138 Python scripts |
| Live sources wired | GA4 · PostHog · Redash · Stripe · Shopify Partner · Intercom · HelpScout · Customer.io · Ahrefs · Sheets |
| Knowledge base | 484 versioned notes, synced to the app on every commit |
| Deliverables shipped | 64 branded documents in 3.5 months |
| Engineers involved | 0 |
844 commits since May 2026 · 38 pages · ~70K lines · 177 migrations
~20 sync jobs · ~30 Postgres tables · 138 Python scripts
GA4 · PostHog · Redash · Stripe · Shopify Partner · Intercom · HelpScout · Customer.io · Ahrefs · Sheets
484 versioned notes, synced to the app on every commit
64 branded documents in 3.5 months
0
Every read runs read-only, least privilege, version controlled. Built to hand over.
FOUR THINGS
The scarce person right now is not the AI engineer and not the ops consultant. An engineer does not know which loop is worth automating. A consultant cannot ship it.
Live KPI dashboards on real billing data
Most companies have a dashboard. Fewer have one wired to the system that actually charges the customer. I build the second kind, on Stripe and Shopify data, and it stays current without anyone filing a ticket.
Data pipelines and lineage repair
The model is usually right. The wiring is usually wrong. I trace each number back to the field it came from, find the rail or the event source it cannot see, and fix the pipeline instead of the chart.
Agent and automation loops
n8n for predictable movement, an agent for judgment. Most jobs are one of each, in that order. The hard part is deciding which loop is worth closing, and that needs someone who carries the number.
Governance and read-only access design
Read-only by default, least privilege, row-level security, agents scoped to named tools. Built so the company can take it over the week it decides to.
FOUR DEFECTS
Four defects from a three-product SaaS portfolio I inherited. All real, all fixed, none of them visible from the chart. Company and product names are left out on purpose, because the mechanism is the useful part.
The churn metric that could only see one rail
Churn was keyed on a Shopify uninstall field. About 74% of that product's revenue bills through Stripe, and a Stripe cancellation never touches that field. The dashboard showed 2 churned accounts in a week where 11 had gone. We had already written a churn-prediction finding off that data and reported a 24× lift. With both rails included it was 12.9×. Still real, half the size, and the wrong number was already sitting in three documents.
Three weeks of zeros that were not zeros
A new-paid funnel stage counted one billing rail. Three consecutive weeks read zero conversions. The real numbers were 3, 1 and 2. It looked like a product that had stopped converting, and it was a metric that had stopped looking.
A tile reading 5, above a table listing 1,168
A product tile reported five automations enabled. The table directly underneath it listed 1,168. The event source was under-capturing by roughly ten times, and the metric was a different flow wearing a stock label. Corrected, the series told the opposite story to the one on the screen.
47 accounts in dunning for years
Forty-seven merchants sat in Stripe past_due for one to three years. They counted as neither churned nor paying, so the revenue number could not see them and neither could retention.
ACCESS WITHOUT BEING A RISK
The fair objection is that one person building on production-adjacent data is a bus factor and a security surface. It came up at Relay in week three. This was the answer, and the company's AI initiative adopted it as the reference for its own guardrails.
Read-only by construction
Every read runs through version-controlled scripts behind a read-only guard. The pipeline reads the products. It cannot write to them.
Least privilege
Reporting layers and a dedicated analytics store, never production app databases. Restricted read-only Stripe keys and a read-only Shopify Partner token.
Row-level security
RLS on every table, and no direct database access from the browser.
Scoped agents
Agents can only call named tools. Output lands in a queue that a human clears.
Built to hand over
The repo moved to the company org. The position I took in the room was that this is a company asset, take it over whenever, I just want to keep evolving it.
THE NEXT SEAT
I am not taking new consulting engagements. What I want next is the same job with more surface, or the version of it that a company is creating right now and cannot fill.
Group GM / VP Operations
PE-backed or roll-up SaaS
The job I do now, across a portfolio rather than one unit. Multiple P&Ls, one reporting spine, and the mandate to build it.
COO
$10M to $50M ARR software
Where the reporting is broken and the data team is a queue. I have run that exact problem and I can show you the repo.
Head of AI Operations
100 to 500 people
This role is being created right now at a lot of companies. Almost nobody qualified for it has carried a number.
START A CONVERSATION
If any of the above is the problem you are hiring against, I would rather talk than send a CV. And if you just want to know whether your own numbers are wired correctly, the check below takes ten minutes.
BOOK A CALL