Customers, not beta users.

The brief thought about what to call the people in the first batch: "early access users", "beta users", "the first batch". Beta describes the state of the product. What we want to name is the relationship. So they are customers, and the programme is built around that word.

Status, from docs/reality.md: shipped v0.1.0 The brief and the memo published in full, never edited, with the corrections file beside them · shipped v0.1.0 A page per customer with the fields the brief asks to track, generated from data/customers.json, with no contact details · shipped v0.1.0 The daily follow-up: three questions, recorded on the customer page as a log · proposed Credit per customer, metered and billed on this site, with a top-up link

Why now

We have a workflow that works: grant, mandate, delta and barrier, with a holder for every row. We have a mapping to what regulators are now asking for, worked through against the FCA's four elements in the Pellbridge agents. And we have a good understanding of how it should all fit together, from a behaviour policy beside the prompt to one for every skill. What is left is execution, and we have the people to execute it with: friendlies who are engaged and motivated. Some are consultants who are going to be selling this and already use some of it. Some are people the lead works with. Some of it is us.

Each customer starts with credit

Each of them starts with credit, £5 or £50 or whatever the number turns out to be, to spend on a site we run. From the first day, what they use is metered, and the question of what they would pay is a real one. That is the same idea as paying after the value: the newsroom gives every reader £5 of credit, each page uses a few pence, and the reader decides when to top up with the value already in front of them. Give it for free until there is enough value that they want to pay for it. The other reason is the one in can you sell it?: a customer who pays is the best signal you will get, and making it easy to pay goes in early, not at the end. Credit, and the meter: what is wired and what is not →

A site of their own

One place where we can follow how everyone is getting on, and where the lead can keep things up to date. It starts with a start-here page: what to do first, in order, with clear instructions. Then a page for each customer, with the objectives and milestones agreed with them, and where they are. The billing is already there on the newsroom; the same works for any site we run: even if all a customer does is use the website, we can measure it, and we can bill for it. The price per use is something to discover.

Hand-holding, on purpose

For this first batch we invest in following up: an email every day if that is what helps, very specific hand-holding, and objectives and milestones mapped out for each customer. That will not scale, and it is not meant to yet. Paul Graham made the case in Do Things that Don't Scale (July 2013): the most common unscalable thing founders have to do at the start is to recruit users manually, and you can give users an insanely great experience with an early, incomplete, buggy product if you make up the difference with attentiveness. Each follow-up asks three things: what they did, what got in the way, and what is next. The follow-up →

The first batch, after the memo

The voice memo of the same day made the first batch concrete. The first users are the lead, the co-founder, and the agents the lead already runs, about ten of them, which are the ones that need behaviour policies. The programme is one people can propose to join, because capacity is limited. The behaviour policies are explicit ones that work with Claude and with ChatGPT, and they cover two of the three places a behaviour policy can run: the rows for the agent, and the rows for the hooks. The agent that is already wired in gets the responsibility and the requirement to produce the end behaviour policy. The milestone is to find behaviour policies that add value to these users, with the onboarding as smooth and effective as it can be made, to the point where it adds a lot of value and they understand what the behaviour policy is doing. The memo, verbatim →

Batches, not a launch

This is a first batch, small enough to follow closely. Alongside it we keep a list: everyone who asks to join is kept for the next batch, with what they want to use it for. The next batch gets a start-here page made from what the first one taught us, and needs less hand-holding per customer. The next batch →

What exists today, in this area

From docs/reality.md, generated on every release. A row that says proposed is described on this site in the future tense only.