Pricing changes are notoriously difficult. Billing code can spread throughout a system, with logic tied to plan names or specific prices. Even small tweaks can have unexpected side effects. I’ve seen teams spend years on a proposed pricing change, only to abandon it due to the technical complexity.

We recently introduced a new pricing model. It took about a month to implement, with agents doing most of the heavy lifting. Our architecture made that possible. This was the first major pricing change to our billing framework, and we barely had to read the code.

exe’s billing layer is pretty simple. About 90 percent of our billing code follows this pattern:

  • A user action or runtime event changes something billable.
  • We record that change as a fact in a database table.
  • A reconciler worker sweeps the table, applies business logic and validation, and calculates a billable quantity.
  • We submit that quantity to Stripe, where it becomes a line item on an invoice.

Half of the remaining code handles subscriptions and collecting payment information—a textbook Stripe implementation. The other half handles LLM credits and yak shaving. Some yaks may not even be yaks. More on this in a later post.

As exe’s billing system has grown, it’s stayed a sleepy process that anyone at the company can work on. It gets numbers, does some math, makes an API call, and waits for the next fact to show up. It’s our kernel space, bound by hard rules. 

But then there is the other half of the whole billing ecosystem: the control plane. That’s our userland. It’s a place where humans have to really think and agents can introduce gnarly bugs. If something breaks, folks get mad. Users are doing all sorts of normal user things like changing credit cards, cancelling subscriptions, and upgrading their plans. Douglas Adams described it well: 

“Anything that, in happening, causes itself to happen again, happens again. It doesn't necessarily do it in chronological order, though.”

The billing side is dictated by reconciliation workers and provider API calls. What’s the equivalent in the control plane? Two models: Account and Account Plan. An Account is a billable entity owned by a user or a team. The Account Plan represents the current billing state of that Account.

Account Plans are the bridge between the two worlds. They reference our internal pricing catalog, which tells the billing side how to calculate the billable quantity and send it to the right price or meter in Stripe.

Our world looks like this:

We’ve (mostly) avoided creating a billing hellscape no one wants to touch. Our recent pricing change put that architecture to the test.

It took a few rounds of feedback, but this architecture let me focus on billing and pricing decisions. The agents handled implementation. I gave them four tasks:

  • Add a new plan to the catalog and configure it in Stripe.
  • Track usage for pools and reconcile the billing.
  • Let users upgrade to the new plans.
  • Show the new pricing on exe.dev/pricing.

I won’t lie. I had reservations about this approach. At launch, I was glued to our internal tools to make sure nothing broke. Sure enough, shortly after launch, the first major issue showed up: a pricing problem.

Alongside pools, we’d introduced a new Work plan that charged for compute instead of seats. It had a $150 monthly minimum that included 4 vCPUs and 8 GB of memory. The billing code worked, but new team signups ground to a halt.

After a few days without a new team signing up, we suspected the $150 minimum was too high. We had agents query our analytics database to investigate and decided to test a lower price. The first rollout had gone smoothly on the technical side. Could we use the same approach to run a pricing experiment?

So we landed on two decisions: cut the price in half and offer a 50 percent off coupon for the first three months. That brought the Work plan’s monthly minimum to $37.50 for the first three months. It would also let teams try exe without a major upfront commitment. The change was done in one afternoon by our agents. After a day or so, Work signups returned to normal levels.

A new major feature backed by two pricing changes that didn't cause catastrophic failures? Oh, and folks who want to keep their current plan can still do so without issue? I think it is safe to say that agents can handle billing just fine. You just have to design the system with agents in mind.