Skip to main content
> AI Operations

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.

> Where this comes from

This is not consulting theory. I am the General Manager of a three-app Shopify division at Relay Commerce, I carry that P&L, and I build the reporting layer for it myself. Everything below is what that job taught me, run on live billing data with real merchants on the other end.

See the seat in full

Read-only, least privilege, version controlled, built to hand over. The repo lives in the company org.

> What I build

WHAT I BUILD

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.

CAP-01

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.

CAP-02

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.

CAP-03

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.

CAP-04

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.

> How the numbers get found

FOUR DEFECTS

Four classes of reporting defect I have found and fixed. Described as mechanisms rather than as anyone's numbers, because the mechanism is the part you can go and check in your own company tonight.

DEF-01
Common

A metric that can only see one billing rail

A company bills through two systems. The churn metric keys on a field only one of them writes. Cancellations on the other rail never touch it, so churn reads low and nobody questions it, because the chart looks healthy. Any finding already built on that series inherits the error.

DEF-02
Common

A funnel stage that reports zero when it means blind

A conversion stage counts one payment path. When the other path carries the conversions, the stage reads zero for weeks. It looks like a product that stopped converting. It is a metric that stopped looking, and the two get treated identically in a review.

DEF-03
Common

A tile and the table beneath it disagreeing

A summary tile is fed by an event stream while the table under it reads the database. The event source under-captures, so the two numbers diverge by an order of magnitude on the same screen. Corrected, the series can tell the opposite story to the one on display.

DEF-04
Common

Accounts that are neither churned nor paying

Failed payments leave accounts in a dunning state with no time limit. They are not cancelled, so retention cannot see them, and they are not collecting, so revenue cannot either. They accumulate quietly for years until someone counts them.

> Governance

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 is worth answering before it is asked. This is the model I run, and it has been adopted as a reference for company-wide AI guardrails.

GOV-01

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.

GOV-02

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.

GOV-03

Row-level security

RLS on every table, and no direct database access from the browser.

GOV-04

Scoped agents

Agents can only call named tools. Output lands in a queue that a human clears.

GOV-05

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.

> What I am looking for

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.

ROLE-01

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.

ROLE-02

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.

ROLE-03

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