How we build

The software is yours. The way we build it is ours.

We call our way of building Earl OS. Everything we build goes through the same production line, starts from what we have already learned, and has to pass an exam before it ships.

The production line

Three phases. A modern way of delivering software.

Every stage ends with something that has to be true before the next one starts, and usually someone on your side who signs it.

Earl OS v1 / Production line

Agree

No code until you have signed off what we are building and how you would run it without us.

EOS-1

Scope

Recorded sessions, a written spec, the exit plan.

Your project manager and Earl sign the spec

Exit plan written: who runs it, and what it costs

Every session recorded and transcribed

You and Earl sign

EOS-2

Design

The architecture in your terms, and the screens.

Your technology team signs the architecture

The people who will use it have seen the screens

Your tech team signs

Build

Written in your repository from day one, tested, and documented so it runs without us.

EOS-3

Develop

From our own patterns, never another club's work.

Every change reviewed by a second person

Written in your repository from day one

Tests and the exam pass before it goes in

A second Earl engineer checks

EOS-4

Test

Tests with the code, and the exam on every release.

The exam score is published

Sent to you on each release

EOS-5

Deploy

Into your estate, versioned, with release notes.

Only releases that pass the exam go out

There is a tested way to undo it

Release notes and a version number

Earl checks every release

EOS-6

Document

A runbook from the work itself.

Your team can run it from the runbook

Your team proves it

Hand over

We stay until your people run it without us.

EOS-7

Adopt

Training on your own data, with us working alongside your team.

Your people use it unaided for two weeks

A named owner on your side

Your named owner signs

EOS-8

Support

Monitoring in your own systems, a warranty, access reviews.

Your engineer ships a change while we watch

You and Earl rehearse the exit plan

What we keep

A head start on every project.

We never start from a blank page. Earl OS is ours. What it builds for you, the code, the data and the IP, is yours. You buy the result, not our hours.

The vocabulary

One agreed definition for each word in this business: a seat, a partner, a right, a benefit, an inventory unit, an activation. It is what allows your data to be compared with outside feeds.

Solved problems

The problems that come up on every build, such as capture with a review queue, extraction that states its confidence, and sign-in with the accounts your staff already use. Each one has a design we reuse, and a note of the traps we have already fallen into.

One fan, one record

Recognising that a ticket buyer, a shirt buyer and a hospitality guest are the same fan. We link the records we are sure of first, use a model only on the unclear ones, and a person can check every link.

Harness and models

The right model for each job, and the harness around it: the instructions it is given and the checks that prove the answer is good enough. Both carry a version number.

Documentation

The same shape every time: what you want, how it is built, who owns what, how we will test it, what we are deliberately not doing, and how your team runs and changes it without us.

The interface kit

A small set of screens we reuse: lists, records, review queues, dashboards. Anything new we build feels familiar on day one.

We keep patterns and learning, never code. Every line written is yours and lives in your repository.

Quality control

Every output has to pass an exam.

The exam is a list of questions we already know the answers to. We run what we build against it, and only software that passes gets deployed.

We write the questions before we build.They come from real work: data, past decisions, past mistakes. They are how we prove our work.
What we build sits the exam and gets a score.How many it got right, out of how many. Code marks the questions with one right answer. A model marks the judgement calls, and a person checks the ones that matter most.
The first score is taken on day one.At your club, before we have tuned anything to you, and again on every release. You see every score.
Every mistake becomes a new question.So the same mistake cannot come back unnoticed.
You can add questions of your own.Keep them back until the test, so we cannot rehearse the answers.

The proof point

AI is non-deterministic. Our exam process fixes that.

We use AI to make everything we build better than the competition. We also use Earl OS to make sure you can rely on the results every time.

Getting started

How every project starts.

The same way each time, so you can decide on evidence rather than on a proposal.

First

Paid discovery

Design workshops with your team, ideally on site: your systems, your rules, your words. You keep what it produces, whether or not we build.

The spec
The ownership schedule
The exit plan

Then

One project, at a fixed price

A fixed price for one project, scoped in discovery and paid in stages, with the final payment tied to the exam score on day one.

Get started.

Start with a conversation about one problem.

Talk to us