I’ve been building software for more than 20 years, most of it for commercial teams. A computer science degree, then a career at global Microsoft partners, shipping software that sales and marketing teams relied on every day. I still write code most days. These days that means directing AI coding agents, with a person reviewing everything they ship.
That’s one of three things Earl brings to a club. My co-founder Neil Kent spent a decade inside the commercial operations of elite sport rights holders, including Chelsea FC and the NFL. Barnaby Ellis spent a decade on strategy and commercial growth for the technology companies that partner with them.
In those 20 years I’ve watched building software get cheaper before. Outsourcing and offshore development made code cheaper to write, but someone still had to know what to build, and own it afterwards. This is similar, but very different. This time the code gets written in minutes, often by your own people.
Opus 4.8, from Anthropic, was a genuine step change in what an AI coding agent could build. Opus 5.5, in September, was another leap. A club with a competent development team can now build its own AI tools and have something working in a fortnight. Getting a first pass is easy now. It’s a different thing to build something enterprise grade and reliable that the club runs every day.
That gap is what a club should pay a partner for. Code is now cheap for everyone, clubs included. What’s worth paying for is everything around it: knowing the sports commercial business, building it properly, and putting AI to work so people trust it.
Can a club really build its own AI tools now?
Yes. A data engineer at a club in the US recently walked us through the internal tool he’s building with an AI coding agent. His club already has a model that recommends ticket prices, and before any recommendation reaches the ticketing system he wants an approval step, where a person signs it off. Nobody had asked him to think about that. He hadn’t built many applications before, and he was “pretty impressed so far with what we’ve been able to do”. It’s the instinct of someone who understands his club’s systems, and most clubs have more people like him than they realise.
So if a supplier’s pitch rests on your team being unable to build, discount it. Screens are cheap now, prototypes are nearly free and demos are quick. We do it ourselves: we built the first version of our own CRM in a summer (the first of many, read on). A first pass is the easy bit. But there are four questions you really need to consider.
Question 1: do they know your business?
This is the part Earl exists for. It means starting from what a seller needs in the renewal cycle, not from a requirements document written by someone who has never sat across the table from a partner. It means understanding the problem completely before anyone writes code, whoever writes it.
Take the word “inventory”. In one system it’s a hospitality box. In another it’s a matchday LED slot. In a partner’s own report, it’s something else again. Until a tool knows what your team means by a seat, a partner, a right and an activation, it can’t compare your CRM export with anything outside it, and every answer it gives is quietly comparing the wrong things.
The hard part of a CRM was never getting the data in. AI makes that ingestion easier. The pain is the mapping and the custom tables. The word migration used to give me chills.
Which partners fit a club is a judgement call too. A club with a premium brand wants premium partners in every category, and a tool that doesn’t know that will cheerfully suggest the wrong one.
The partner worth paying arrives with that vocabulary already worked out, and fits your club’s words into it rather than the other way round. They’ve also built this kind of thing before. Anyone can write a capture pipeline once. Almost nobody has written seven and knows which parts to keep.
Question 2: can they build it properly?
The tool your partnerships team relies on has to meet a much higher bar than a demo. When a partner asks what their activation delivered last season, the answer has to be right first time, with messy data, in the week before a renewal, when the person who built the tool is on leave. It has to cope with a season’s worth of changes to people, partners and deals. Getting from a working demo to that standard is most of the work.
Design decides whether it gets used at all. AI coding might be approaching a solved problem (I say “might”, it’s a whole other conversation), but design and UI made by AI is still a little on the “slop” side.
Clubs know this already. A head of strategy at a US club told us: “We don’t think there’s one solution that’s going to just come in and fix all of our problems with AI.” Not without adoption and training for their own people, and the right data underneath. The data is rarely the hard part. Getting people to change how they’ve always worked is.
The tools that fail live in yet another tab. They want their own login. They give answers with no way to see where the answer came from, so nobody trusts them. The tools that last are duller and harder to build. They use the sign-in your staff already have. They read from the systems your commercial team already lives in, rather than asking anyone to keep a second copy. They show their evidence, so your sales lead can click through to the email or the contract behind a claim. And when they aren’t sure, they put the question in a review queue for a person instead of guessing.
Question 3: can they put AI to work well?
AI is as confident when it’s wrong as when it’s right, and the club’s name is on everything the commercial team sends to partners.
We see this first-hand, because Earl runs on its own tools. When our meeting transcriber’s live feed dropped out, a backup model listened to an empty room and reported someone speaking Russian. On another call it wrote “Bye.” over and over, for a whole paragraph. The AI in our CRM once linked a mention of Google Cloud to Oracle, with a perfectly reasonable explanation attached. No benchmark would have caught any of these. Our own tests did.
Putting AI to work well means knowing when a model shouldn’t be in the loop at all, as that data engineer knew about ticket prices. It means making the tool show its working, and say “I’m not sure” instead of inventing. And it means an exam: a set of questions with known answers, taken from work that has already happened, rerun every time the model underneath changes. Say a tool suggests a betting brand to a club in a league that bans gambling sponsors. We add that exact case to the exam, and every future version has to get it right before anyone relies on it.
The models underneath will change, and not always by choice. In June the US government barred Anthropic’s newest model, Fable 5, for anyone outside the US, overnight. The engine behind our own transcriber has changed three times since May, and the job it does hasn’t changed once. A tool that breaks every time a lab ships something, or a government acts, leaves your commercial operation depending on someone else’s decisions.
Question 4: how is it built, and where does it run?
The last question is the one a CTO should ask first. What do you want your team maintaining for the next few seasons, and what happens to it when the person who built it moves on?
The same risk applies to suppliers, us included. In 20 years I’ve inherited plenty of software whose author was long gone, and the first job was always working out what it did and who was meant to run it. So we work on the assumption that a club should never need us to keep the lights on. Everything we build sits in the club’s own repository, runs in the club’s own estate behind the club’s own sign-in, and comes with written steps for running it without us. If Earl disappeared tomorrow, your team should be able to carry on.
Getting things right
So before you sign with any partner, including us, ask four things:
- Do you know our business? Ask what they know about how a sports commercial team works: partners, rights, renewals, hospitality, matchday. A partner who says yes to every problem hasn’t understood yours.
- Can you build it properly? Ask who writes the code, who reviews it, and what they’ve built and still run every day themselves.
- How do you put AI to work well? Ask how the tool shows its evidence, where a person signs off, and to see the exam. Ask whether your team can write some of the questions itself.
- How is it built, and where does it run? It should run in your estate, behind your sign-in, from your own repository, with the written steps for running it without the people who built it.
Most organisations I talk to are still early. AI smartens up the presentations and stands in for Google search. That’s fine. Basic, but fine. What’s missing is anything built around it that a commercial team would miss if it went.
That’s the bar for AI in sport: something your commercial team would miss.
Frequently asked questions
Should a club build its AI tools in-house or use a partner?
Both can work. If you have a strong developer and a narrow, well-understood problem, building in-house is a real option. A partner earns its place when the problem needs commercial judgement, careful design and a way of testing answers that your team doesn’t have time to build.
How do you test an AI tool when its answers keep changing?
Write the exam first, from work that has already happened, so you know the right answers. Score the tool on day one, before anyone tunes it, and again on every release. Keep every wrong answer as a permanent question.
What happens when the AI model underneath changes?
Plan for it every couple of months, and make it boring. A well-built tool treats the model as a replaceable part, so the job it does for your commercial team stays the same.
Who should own an AI tool built for a club?
The club. The code, the data, the outputs and the documents should sit in your own repository, with the written steps for running it without the people who built it.