Your new backend, defined in English

What happens when a customer cancels?

Somebody in support needs to know, and the question has to go to a developer, because the answer is in the code. They read the code and come back with: the refund is prorated, except on annual plans, which nobody remembered. The help page says something different. The person who wrote that rule left last year.

This happens everywhere and it is nobody's fault. Rules pile up in code. Code is readable by a few people who are already busy. Everybody else is going on a document that stopped being accurate.

Changing a rule runs into the same wall from the other side. You describe what you want and wait. What comes back is what you asked for, as far as you can tell.

The plumbing is already there

A flow describes one operation: what it takes in, the rules it applies, what it returns, and what happens when something is wrong. A flow says nothing about how people sign up, how passwords are checked, how sessions are issued, how data is stored or how a caller is rate limited. All of that comes with typestate and works the same way for every customer.

That split is the reason a definition stays short enough for somebody to actually read it. A description that also had to cover its own login checks and its own database queries would run to pages, and nobody checks pages carefully.

How an engagement works

1. A first conversation covers what the backend has to do, in proper detail.
2. Your backend gets built on typestate. The definitions are English sentences describing your data, your operations and your rules.
3. You read them and say where they are wrong. Normally you could not do this, because what you would have to check is source code.
4. Later changes come to you as an English diff and go to production once you approve them.

Your backend gets maintained for you after that. Because the definitions stay readable, the system does not turn into something only its author can operate.

Where this differs from prompting

Describing software in English and getting working code back is not new any more. The difference is what happens to the English afterwards.

A prompt produces code and then stops mattering. From that moment the code is the only accurate account of what the system does, the document you wrote for people goes stale, and you are back where this page started.

typestate keeps the English as the definition. Every change edits the definition and recompiles from it, so version history is a history of your rules in English, and the compiled code cannot be edited by hand at all. The sentences on screen a year from now are still what the system does, because those sentences are what produced it.

A release to production is a set of changes somebody approved. Editing any definition inside an approved release cancels the approval, so what goes live is what was read and agreed.

typestate runs on typestate

Sign-in for the typestate control panel is a typestate backend. Accounts, sessions and access checks are English definitions, compiled and deployed the same way a customer's are, carrying real traffic.

Who this fits

A small team with a product already in front of customers, whose backend rules change often enough to be annoying, and where somebody outside engineering needs to check that a rule is right.

typestate is a poor fit for a large existing system that would need migrating, and will not help a backend whose main problem is load.

Get in touch

typestate is in private development and takes on a few companies at a time. Describe what you are working on and you will get a straight answer about whether this is the right fit.

Contact