Pricing

A billing model your books understand.

Retainers, subscriptions, metered usage, prepaid credits, custom terms — express how you really charge as typed obligations, so the same pricing that wins the deal recognizes correctly and reconciles cleanly as MRR, deferred revenue, and margin in real books.

PLAN · GROWTHRetainer$2,000/moUsage$0.02/callCredits10k prepaidMRR$2,000Deferred rev$200Margin71%

You set your price by copying a competitor's site, then never learn which plan pays

The first price is a guess. You open two competitors' pricing pages, land on $200/month with some usage on top because it looks about right, and ship it. The guess isn't even the expensive part — it's that you never find out whether it was a good one. Usage pricing especially is easy to announce and extremely hard to run: consumption makes revenue hard to predict, and the mess surfaces downstream as non-payment, churn right after signature, and refunds on volume nobody consumed. The number lives only in a Google Doc, so you're flying blind on the one question that matters — which tier actually makes money.

Every new deal, you rebuild the same model by hand

Then the second customer signs, and the third. Each time, the retainer, the subscription, the metered overage, the prepaid credit pack get flattened into one flat invoice you assemble from scratch and explain line by line. The pricing lives in prose, so recognition is manual: recurring should spread over the term, usage should land as it's consumed, and none of that happens on its own. Every quirk becomes a finance handoff. This is founder-led data entry at its worst — the same setup, retyped, deal after deal, with a fresh chance to get it wrong each time.

Define the plan once; your agent spins up the contract and invoice in one line

Describe how you charge in plain language to the agent you already use. It sets up a named plan — retainer, fixed fee, subscription, metered usage, prepaid credits, per-call — as typed obligations, not a flat line, and applies it to each new deal without re-typing the model. The standard customer bills the standard way; the one-off exception is still just a line on top. Invoices bill straight from the plan, so what you quoted and what you charge always match, and each charge type recognizes against the right revenue account on its own.

The plan — typed once
Pro — $200 / month + usage
  • recurring · $200 / month
  • usage · $0.01 per call over 10k
One line later
Contract + first invoice
  • create_contract_from_plan ✓
  • invoice bills from the plan — quoted = charged
On the books
Recognized MRR
$200
recurring revenue, recognized monthly — per tier
One plan definition, typed once — the contract and first invoice spin up from it, and the charge lands as recognized recurring revenue. Margin per tier reads out below.
Set up a plan and reuse it
Our Pro plan is $200/month plus $0.01 per API call over 10k. Set that up as a reusable plan, put Acme on it, and show me what it looks like as MRR and margin once a few customers are on it.

Because revenue and cost are tagged per plan, your books tell you which tier is profitable

This is the pain you couldn't see before: not the price, not the setup, but never knowing your margin per tier. Revenue and cost are kept per plan and engagement in the ledger, so which pricing actually makes money comes from your real books — not a separate model you'd have to build. You can preview your Economico fees for a month before you bill, so you set the next price knowing your cost of the rail. The guess becomes a number, and the next number is set with data. It's all live today: typed obligations for one-off, recurring, and usage charges, invoices billed from them, margin per plan straight from the ledger — no pricing dashboard to maintain.

Pro plan margin
68%
revenue less tagged cost
Starter plan margin
41%
after usage overages
Pilot tier contribution
($800)
this quarter — time to reprice
Margin per plan, straight from the ledger — the guess becomes a number.

"I already use Stripe for subscriptions"

Stripe charges the card and runs subscriptions well — it's optimized for the self-serve payment use case. What it doesn't do is make contracted, billed, paid, recognized, deferred, and margin-per-plan one ledger your agent can query. Here the pricing is the revenue model your books understand: recognized correctly, reconciled contracted-vs-used-vs-paid, on one connected ledger your own agent runs. Reach for a billing or merchant-of-record system like Chargebee or Paddle when subscription operations, tax, or global payments are the main job; Economico isn't replacing those, it makes the pricing land cleanly in the books from the first customer. And if your pricing is just one number today, that's one obligation — clean recognition and a base to grow from. See founder analytics.

Get started

Turn a price into a contract, an invoice, and a margin number

Connect the agent you already use and your pricing — however you bill — becomes structured revenue in real books.