Three roles, one fleet: why we're building the best tech company out of the UK

The Team Talk (Alex's version)

SHOT is a sports platform built in the UK by a team you could fit in a car, with room for the kit. This blog is about the other squad: the machinery.

Here is the honest picture. SHOT is led by a tight product-engineering core: a CTO focused on architecture and data, a chief engineer focused on the product and platform, and a product-led CEO focused on building the infrastructure sport actually needs. Behind them sits a fleet of AI workers: robots that write and check code, test the product every morning by using it like real players and coaches do, watch a WhatsApp group for bug reports and file them properly, and once built an entire season-by-season coaching playbook for every sport on the platform in four days.

Big Silicon Valley companies write famous blogs about how they build things. Netflix did it. Amazon did it before the world knew what AWS was. We read those blogs from a spare room in Britain and decided the honest response was not admiration, it was competition.

So this is our version, with one promise: receipts. Real numbers from our own logs, costs in pounds, and write-ups of the things that broke, not just the things that worked. When we get something wrong, you will read it here first.

For the kid on the far pitch, none of this matters until it makes their coach better and their club stronger, which is the whole point of the machine.

The Deep Dive

The claim

We think a small UK product-engineering operation can run at a standard that bears comparison with well-funded Silicon Valley product teams, and we intend to prove it in public. Not with thought leadership, with logs.

The comparison we care about is practice, not headcount:

• Review. Our pull-request review is a declarative program of parallel AI reviewers (a distinguished-engineer pass and a security pass run concurrently), tuned from 7 AI sessions down to 4 for roughly 40% less token spend, with a human holding the only merge key to production.
• Verification. Every morning, synthetic athletes and coaches live a full evaluation cycle through the real product API under their own credentials, and an invariants job turns red if the product's story stops making sense. We do this because we measured that green click-through tests lie.
• Manufacturing. When the product needed a development playbook for every sport at every level, a supervised fleet of headless AI workers built 300+ frameworks in four days across 4,600+ worker sessions, every fragment passing a deterministic quality gate before it counted.
• Cost. We treat tokens the way good companies treat cloud spend: measured, routed by model tier, and engineered down with the same seriousness as any other line on the P&L.
• Safety. The platform serves young athletes, so our in-product AI is gated by a battery of adversarial evaluations we wrote against ourselves, run in CI on every change.

None of that required a platform team. It required an operating system: conventions, gates, memory and playbooks that any model can plug into. The models are rented and improve on someone else's schedule; the operating system is ours and compounds. That asymmetry is the entire thesis, and most of the tooling that implements it is open source, which we consider a feature of the strategy rather than a leak in it.

Why publish

Three reasons, all selfish, all stated openly.

First, writing forces rigour. A pipeline you can explain to a stranger is a pipeline you actually understand, and several of the improvements described on this blog exist because writing about the old version was embarrassing.

Second, the companies whose engineering we respect all documented their way of working before the world had a reason to care: Amazon's scale thinking before AWS, Netflix's chaos engineering before anyone copied it. The pattern is consistent: the writing preceded the platform, and made it credible. We are documenting the way of working now because we believe the way of working is the company.

Third, the UK produces excellent engineers and exports too many of its ambitions. We would like SHOT to be evidence for a different pattern, and a blog with receipts is harder to argue with than a pitch deck.

The rules we publish under

• Every post carries two layers: a plain-English version fronted by Alex that a coach or a parent can read in a minute, and a signed technical deep dive underneath. If we cannot explain a system simply, we treat that as a defect in the system.
• Every number is from our own logs or flagged as unverified. We do not publish other people's benchmark claims as fact.
• Failures get written up with the same care as wins, but only when the underlying story has been verified against real project history.
• Nothing publishes that could compromise the platform or the young people on it.

What's coming

The opening run: the fleet that built our coaching playbooks, what running a company on robots actually costs, two frontier models racing to solve a real production incident, the digital twin that plays a full season every morning, the review pipeline that pays for itself, and the reliability rule we never break: no robot acts alone. Then the kit: why our agents travel light, how we attack our own AI before anyone else can, the operating system we own, and the secret sauce we keep on GitHub.

Next in The Engine Room: 322 playbooks in 4 days: our first fleet.