Skip to main content

In development. Ceodore is being built. Some of what is described here is finished, some is not, and we say which on every page.

Where we are up to
ceodore

We built this in Britain on purpose

The sensible move was America: bigger market, looser rules, more money. We did the opposite, and it has cost us time we are not getting back.

Build it loosely, adapt it later rebuild, twice Build it to the strictest rules first works elsewhere already

If you are building anything in this industry, the advice is consistent. Go where the market is bigger and the rules are lighter. Get moving, get customers, deal with regulation when you are large enough to afford lawyers.

It is good advice, and it is probably right for most people. We ignored it, and it is worth explaining why rather than pretending it was obvious.

Strict rules are a specification

The thing about building somewhere with demanding rules is that the rules tell you what good looks like. You are not guessing at what a regulator might eventually want; it is written down, at length, by people who have thought about it harder than you have.

Build to that and the hard questions get answered at the start. Who holds the money. What happens when something fails. What has to be recorded and for how long. Which activities need permission. Those answers shape the architecture, and architecture is the one thing that is expensive to change later.

Build somewhere permissive and you defer all of it — which is genuinely faster, right up until the point where the deferred decisions turn out to be load-bearing.

The accounting is not a localisation

This is the part that convinced us.

Most software treats tax as a settings problem. Rates in a table, a different form at the end, a bit of copy in the right language. For anything touching stablecoins, that is wrong in a way that only shows up at the end.

VAT at the sterling value at the time of supply is a structural requirement — it means you must capture a number at the moment of a transaction that cannot be recovered afterwards. Section 104 pooling with same-day and thirty-day matching is a genuinely different algorithm from per-wallet FIFO. These are not settings. They are the shape of the thing.

You can add a language. You cannot add a cost-basis method to a product that assumed a different one.

So we wrote the tax engine as an interface with one implementation, and the cost-basis engine as another. Adding a country later is an implementation rather than a rewrite. That decision only gets made if you take the hardest case first.

What it has cost

  • Time, straightforwardlyMonths spent on pooling rules and VAT treatment that a looser product would have skipped entirely and shipped without.
  • A smaller market to start inBritain is not America. The addressable market for a UK-first accounting product is a fraction of the size, and every investor would tell you that.
  • Capabilities we cannot haveNo custody, no swaps, no transaction fees. Each of those is revenue or convenience we have given up because of what it would make us.
  • Waiting on other peopleSterling stablecoins exist but none is yet authorised under the new regime, and the ones circulating are small. We are ready for a market that has not arrived, which is an uncomfortable place to be.

What it bought

A product a British accountant will sign off, which is the actual gate. Not the technology, not the fees — whether the person doing the year end is comfortable.

Servers, database and backups in the United Kingdom, under UK law, which is the answer your own auditors will want without you having to ask.

And a plausible route outward. Ireland is largely a data exercise. The EU is a variation on the same shape. The United States is a different tax type and would be an integration with a specialist rather than something we would build. None of that is easy, but none of it requires starting again — which it would if we had built for the easy market and tried to reverse into the strict one.

The thing nobody says out loud about the permissive route. It works until the rules arrive, and the rules always arrive. Then you are retrofitting compliance into a product whose foundations assumed it would not be needed, usually at speed, usually while customers are already using it.

Doing it in the other order is slower and duller. It is also the only order where the answer is right the first time.

The architecture page sets out exactly what that decision produced, including where the limits are.