Reckon is free and stays free. What I sell is the judgement behind it — the design work of making a real product behave, and of writing rules that fit a codebase somebody already has.
No tiers, no seats, no renewal. Reckon is free and stays free — what I sell is the work of applying it to a product that already exists.
The rules, the components and every worked product. Clone it, point the tokens at your brand, and use it on client work without asking me.
Free because the rules are worth more once people use them.
I wrote these rules over twelve years of building this kind of software. The layer is free; the judgement behind it is what I do for a living.
Each one begins the same way: a call, then a written scope with a fixed shape. No discovery phase billed by the hour.
01How to use →An operational tool taken from a brief to screens a team can build, with the awkward states drawn.
Tokens, components and the conventions around them, documented so the next person does not have to guess.
Reckon adapted to what you already have: your components, your naming, your domain and its states.
A review of what your agents are producing, and the rules that would stop it happening again.
Not that it looked better. That the screen agreed with itself, and nobody had to check.
02Straight answers →Eight screens that felt like they were designed by the same person on the same day. That is the part I could never get out of a generator.
An invoice behaved like an invoice on every screen it appeared on. Same label, same states, same actions available in the same order, whether it was a row in a list or the whole page. We used to lose a week reconciling those differences after the fact — three designers, three mental models of the same record, and nobody noticing until QA. Here the model of the domain was decided once, and everything downstream inherited it.
It stopped giving me a dashboard when what I described was a queue. Somebody has clearly thought about the difference between software you read and software you act in — and the numbers on it are load-bearing rather than decorative, which is the same insight applied twice.
The most severe row is the one you see first. Sounds obvious. Nothing else does it.
Empty, permission-denied, filtered-to-nothing, the record somebody archived last week. Those screens are most of the actual experience in an internal tool, and they are the ones that never make it into the mockup that gets approved. Having them arrive designed changed what our handoff even means.
The questions a sceptical lead asks before they will put an unfamiliar file in front of their team.
03Back to the top →It ships components and tokens, but that is not what you are buying. The product is the rules layer that decides what gets computed, what gets shown and what gets refused — plus the machinery that makes those rules checkable.
It is built for Claude Design users generating business UI. Because the layer is plain markdown loaded as project instructions, anything else that reads a rules file will use it too. There is nothing proprietary to integrate.
The tokens are yours to set and brand fit is a config change. The judgement rules are not configurable, because that is the product. If you want a different opinion about derivation, you want a different product.
The rules are written against behaviour rather than internals, so upstream releases move underneath them. Where a rule does need to change, it changes in one file you can read in an afternoon.
Marginally slower on the first generation. Considerably faster by the fourth, because you are not re-prompting it to fix a total that never tied.
Reckon
Components are the easy part. What you are missing is the layer that decides what gets computed, what gets shown, and what gets refused.