A plan is a list, not a tier.

Composable pricing sells a product as a list of parts, each carrying its own price, and charges you the sum of the ones you switched on. It sounds like a billing decision. It isn't: the moment a plan can be a different shape for every customer, the interesting question stops being "what does it cost" and becomes "what, exactly, is a part allowed to stop you doing".

Why almost everything is sold in tiers

Good / Better / Best is not a discovery about customers. It is a discovery about invoices. Three columns collapse a product into three prices, three entitlement states and three upgrade paths, which is roughly the smallest amount of machinery a business can get away with. Everything downstream — the pricing page, the paywall, the renewal email — has three cases to handle instead of an unbounded number.

The cost lands on the person who wanted one column's worth of one tier. Tiers bundle by persona ("Pro", "Team") rather than by use, so the ratio of what you pay to what you touch is a matter of how closely you happen to resemble the persona the packaging was drawn around. Most people don't resemble it very closely.

Unbundling fixes the ratio and immediately creates three problems that tiers never had to answer. They are worth walking through, because the answers are the actual design.

Problem one: what is a part?

Not every capability can be a line item. Some of them are load-bearing — take them away and the rest of the product stops meaning anything. In a system that moves money, that floor is money movement itself: a wallet, deposits and withdrawals, bridging and swapping between chains, the planner that goes and fetches what a trade needs. You cannot sell somebody a betting screen and then sell them the ability to get money to it, because the screen without the money is not a product, it's a picture.

So a composable plan has a shape: one base that is always charged, and a list of add-ons that are genuinely optional because dropping one leaves a coherent product behind. amparo's base is 2.00 USDC per two-week block and carries the wallet, money in and out, bridging and swapping, the funding planner, the dashboard and the tax records. The six add-ons are what you do with money once it can move.

Problem two: what does a switch switch off?

This is the whole design, and it is where unbundled pricing usually turns nasty. Rendering seven toggles is an afternoon. Deciding what each toggle is permitted to stop is the part that determines whether your pricing is a choice or a hostage situation.

The naive implementation gates a screen: no Markets module, no Markets screen. Then somebody drops Markets with three open positions on it and discovers their money is behind the paywall. They now have to pay to leave — which is not a subscription, it's a lock.

The rule that avoids this is narrow and worth stating exactly: a module owns the endpoints that open new exposure inside it, and nothing else. Reads, exits, cancels and withdrawals are never gated. That asymmetry runs right down into single screens — on a market you already hold, the BUY is gated and the SELL beside it is not, because one of them starts something and the other one ends it.

Problem three: parts share plumbing

Modules are a story about the product. The code underneath is a story about rails, and the two do not line up one-to-one. The same order rail is reached from a betting board and from a matched-betting planner; the same swap rail converts a deposited token into the currency a venue wants, which is money movement whichever screen calls it.

A one-endpoint-one-module map handles this badly — you either duplicate the rail so each module can own a copy, or you charge somebody twice for one pipe. The fix is to make the gate an any-of set: the endpoint names every module that legitimately opens it, and holding any one of them is enough. And rails that are really plumbing stay in the base even when they live behind another part's screen, because gating them would break money in and out for everybody.

The arithmetic has to be done in one place

Two numbers can drift apart: the one on the screen and the one you are charged. In a tiered system there are three of each and somebody notices. In a composable one there are 2⁶ possible plans, and a mismatch can hide in a combination nobody on the team has ever selected.

The only defence is that the catalogue — which screens a part owns, what a part costs, what it is called — exists exactly once, on the server, and the client is shipped it rather than keeping its own copy. The plan builder renders the prices the backend will charge because they are the same values, arriving over the same request that says which parts you currently hold. Add a part, or move a screen from one part to another, and both sides move together or neither does.

The same principle decides who computes the bill. The client never sends an amount, only which parts it wants; the server prices that set, and after the payment lands it re-prices the same set against what actually arrived on-chain. A client that asks to be credited more than it paid for fails at the last step, not the first.

The rule that surprises people: a renewal can only widen

Say you hold Markets and you want to add Trading. What should you be charged? The tempting answer is "the price of Trading" — and it is wrong, because that payment also pushes your expiry date out, which renews Markets too. Charge the add-on price and you have sold two weeks of a 3.00 plan for 1.00.

So every step of a payment re-derives the effective set: what you asked for, widened by whatever your still-active membership already carries. Adding Trading to a live Markets plan quotes base + Markets + Trading, and the block you buy renews all of it.

The honest consequence, which follows directly: you cannot shrink a block you have already paid for. Dropping a part takes effect when the current 14 days run out, and until then it stays switched on in the builder — because the alternative is a button that silently forfeits time you bought. There is no proration in either direction.

What you actually pay, and how

Membership runs in 14-day blocks, bought one, two or four at a time. Payment is a plain USDC transfer on Polygon from your own wallet to a fixed address: the server builds the unsigned transaction, your browser signs it, and it is credited only after the receipt confirms and a matching transfer log for at least the expected amount is found on-chain. The transaction hash is the payment reference and it is unique, so a payment credits exactly once.

Two consequences fall out of that and they are the real difference from a card subscription. Adding time stacks: the new expiry is whichever is later of your current expiry or now, plus the days you bought — so paying early never costs you the tail of what you already had. And there is nothing to cancel, because there is nothing on file to charge. A membership ends by not being renewed.

A 7-day trial with every part switched on starts at first login, which means the first plan most people build is a subtraction from the whole product rather than a guess about it. The pricing page has the builder with the live numbers in it.

What this model is bad at

It is worth being straight about the trade. Composable pricing is harder to explain than three columns — "from 2.00" is a floor, not a price, and the reader has to do a small amount of work to find their own number. It has no upgrade moment, which is a real loss if you were relying on one. It makes support harder, because every account is a slightly different product and "it doesn't work" now needs a plan read before it can be answered.

And it only stays honest while the invariants hold: one catalogue both sides read, a gate that stops nothing except new exposure, and a price the server recomputes rather than accepts. Break any one of those and you have a tiered product with extra steps and a worse paywall.