Usage-Based Billing for Solo Founders in 2026: What Stripe, Metronome, Orb, Lago and Stigg Actually Cost

If your product burns money every time someone uses it, a flat monthly fee is a slow way to lose money. I have watched founders quote $29 a month for an AI product and then discover their heaviest user costs $9 in API calls per day. One customer, one invoice, and suddenly the “profitable” tier is running at a 4% margin.

That is the whole problem with per-seat pricing for consumption products, and the whole reason usage-based billing exists. The question is no longer whether to meter. It is which metering stack you build on and what it actually costs you per month.

I went through the published pricing for every major usage-based billing platform as of November 2026, including the big change Stripe made this year. Here is what a solo founder actually pays.

The billing stack is now four separate decisions

Most people think usage-based billing is one purchase. It is four, and each one can be made independently.

1. The payment processor. This is who moves the money. Stripe is the default for a reason.

2. The metering and rating engine. This counts events and turns them into billable quantities. This is where most of the actual work lives.

3. The invoicing layer. Turns quantities into an invoice, handles proration, mid-cycle changes, and credit notes.

4. The entitlement layer. Decides what a customer is allowed to do right now, including hard caps and rate limits before the invoice arrives.

You can buy all four from one vendor, or split them. A lot of the confusion in this market comes from vendors who show you a headline number and hide which of the four they are actually selling you.

What changed in 2026: Stripe moved usage billing to Metronome

This is the single most important thing to know if you are evaluating billing right now, and a lot of blog posts have not caught up to it.

Stripe completed its acquisition of Metronome in January 2026. In July 2026, Stripe unbundled usage-based billing out of its own Billing product. The pricing change is subtle but real.

Before the split, billing at 0.7% covered recurring, usage-based, and one-time billing under one rate. After the split, 0.7% covers recurring and one-time billing. Advanced usage-based billing moved behind a separate conversation with Metronome.

Stripe’s own docs now describe Metronome as the recommended path for usage-based billing, with a dedicated migration guide. Stripe Billing’s own pricing page lists Metronome under “Included” but routes you to “Contact Metronome” for anything beyond the basics.

Here is what this means practically. If you read a 2025 guide that said “Stripe Billing costs 0.7% and includes usage-based,” that advice is out of date. If you are starting fresh with metered billing, the real comparison is Stripe plus Metronome against standalone Metronome, Orb, Lago, or Stigg, not against “Stripe alone.”

Stripe Billing: the cheapest way to move the money

Stripe Billing pricing is straightforward on the payments side.

Pay-as-you-go pricing is 0.7% of billing volume with no recurring fee. That is the cheapest entry point for a founder whose revenue is lumpy or still small. If you process $20,000 a month, that is $140.

Volume-tiered subscription plans run on a 1-year contract, paid monthly, and you get better rates at higher volume. The catch for a solo founder is the annual commitment before you know your volume.

Beyond billing, you are still paying the standard Stripe payments costs: 2.9% plus 30 cents per successful domestic card transaction, plus 1.5% for international cards, plus 1% if currency conversion is needed. Disputes cost $15 each regardless of outcome, and countered disputes are another $15. Usage-based billing does not get you out of any of that. It is a separate percentage stacked on top of the payment cost.

So a $100 usage-based invoice from a domestic card customer costs you roughly $3.20 in processing before you add the billing platform fee. Budget for the stack, not just the meter.

Metronome: the Stripe product that does the metering

Metronome is now the Stripe-native option for usage-based billing. It handles real-time metering, pricing models, invoicing, and reporting.

The pricing is published in tiers. The Starter plan, aimed at teams launching usage-based products, bills billing volume at 0.8% plus events volume at $0.04 per 1,000 ingest events.

Do the math on that event rate. If your product generates one event per API call, a customer making 50,000 calls a month costs you $2 in ingest. Fine. If you are metering every token, every request, and every workflow step, that number climbs fast. Some Metronome plans also require talking to sales, and Metronome has historically gated rates behind a conversation, so plan on getting quotes rather than assuming the public rate is what you will pay.

What you get for that: SQL-based billable metrics, so you can query raw events without pre-aggregating them. Centralized rate cards, commits, and credit models. Per-customer pricing with discounts and amendments, scheduled to take effect now, in the future, or retroactively. Native payment integrations with Stripe and cloud marketplaces. That last one matters more than it sounds if you ever sell through AWS Marketplace or Google Cloud Marketplace, because that revenue does not count the way a Stripe charge does.

Metronome is the right call if you are already deep in Stripe and need real usage-based billing rather than seat-based subscriptions with a token allowance bolted on.

Orb: the cleanest self-serve option

Orb dropped its Core and Advanced tiers in October 2026 and consolidated into a single self-serve Business plan priced per credit.

The Business plan is $6.00 per credit, with volume discounts available. One credit covers $1,000 of billable usage. Enterprise is custom-priced with a sales conversation.

That per-credit model is a genuinely nice design for a founder. You are not billed a percentage of revenue that grows silently as you succeed. You know exactly what your billing infrastructure costs before you have a customer. If you are processing $10,000 of billable usage, you are looking at $60 in Orb credits per month. That is a fixed, knowable number, which is more than most founders can say about their current stack.

Orb takes usage events through an API or cloud storage, computes SQL-based metrics, issues invoices, and links payment, accounting, tax, CRM, and accounting workflows together. It is built for teams billing by usage, seats, fixed charges, or a mix of all three.

Stigg: metering plus the guardrails

Stigg takes a different angle. It positions itself as a usage runtime that decides what every customer, user, and agent is allowed to do, with credits, entitlements, metering, and governance in one enforcement layer.

The pricing is published clearly, which is more than you can say for most vendors in this category:

• Build is free. 10,000 managed entities per month, 5 million events per month, 1,000 events per second.
• Pro is $399 per month on an annual contract, or $499 month to month. 10,000 entities, 25 million events per month, 10,000 events per second.
• Scale starts at $50,000 per year, annual contract only.
• BYOC (bring your own cloud) starts at $150,000 per year.

A managed entity is any object Stigg makes a real-time enforcement decision for. One customer with three subscriptions and two wallets counts as one entity. Sandbox and inactive objects do not count.

The free tier is the most generous thing in this market. Ten thousand entities and five million events per month at zero cost is enough for a solo founder to run a real product, not a demo. The rate limit of 1,000 events per second is the constraint to watch, and at the Build tier the ceiling is hard: when you hit 10,000 entities, new entity creation pauses while existing enforcement keeps running.

One feature worth knowing about: seat-based credit pools. You link a recurring credit grant to a metered feature, and the customer’s balance scales automatically as their team grows. That solves a specific problem, which is that you want metered pricing but your customer still wants to see a predictable seat count on the invoice.

Lago: the open-source path

Lago is open source, and that matters for a different set of reasons than the others.

The pricing page is split between Lago Cloud (managed) and self-hosted deployment. Lago Premium is available on both, which is an unusual combination: you can run the same commercial tier on your own infrastructure. The page lists SOC 2 Type II, role-based access control, and deployment options including on-prem and your own VPC.

The self-host path appeals if you have an ops-heavy founder who does not want a per-transaction billing percentage. The trade is real: you are running a billing service, which means uptime, upgrades, and a Postgres database are now your problem. For a solo founder, that is usually a bad trade at the start. It gets better when you have customers whose contracts require data residency or a private deployment.

Lago also has the most flexible event model of this group. Its API sends events with dimensions and properties, and you define aggregations and plans against those. That flexibility is exactly what makes it attractive for products with unusual usage patterns, and also what makes it the most work to set up correctly.

Real cost math for a solo founder

Let us take a concrete case. You run an AI product. You have 200 paying customers on a $49 plan, and the plan includes 500,000 tokens. Your average customer uses 340,000 tokens. Your top five customers use between 1.8 million and 6 million tokens each.

Option A: Stripe Billing pay-as-you-go, no metered pricing.

You bill flat $49. Total revenue is $9,800 a month. Stripe takes 0.7% of $9,800, which is $68.60, plus 2.9% plus 30 cents on each of 200 card charges. That card cost is $284.20 plus $60 in fixed cents, so $344.20. Total payment and billing cost: roughly $413, or 4.2% of revenue.

Now the part that does not show up in that number. Your API cost per customer averages maybe $0.90 at 340,000 tokens. But your heaviest customer at 6 million tokens costs you about $16 in API calls for a $49 payment. If that pattern holds across 50 customers, you are losing money on exactly the customers you most want to retain, because they are also your best advocates.

Option B: Metronome Starter.

Billing volume at 0.8% instead of 0.7% costs you about $9.80 more. Events at $0.04 per 1,000 depend entirely on how granular you meter. Meter one event per API request and you are fine. Meter every token and a 6 million token customer generates 6 million events, which is $240 in ingest for that single customer.

This is the trap in usage-based billing, and it is not obvious until it is expensive. How you meter is a pricing decision, not just an engineering one. If you meter per token, you are charging your own infrastructure costs twice, once to Stripe and once to Metronome.

Option C: Orb Business.

$6.00 per credit, one credit per $1,000 of billable usage. At $9,800 of monthly billable usage, that is 9.8 credits, so $58.80. You still pay Stripe’s processing on the underlying transactions unless you route through Orb’s payment integrations. Your billing infrastructure cost is fixed and predictable at about $59 a month.

Option D: Stigg Pro.

$399 per month on an annual contract. That is more than the entire revenue-based fee on options A and B, by a wide margin. It buys you something different: real-time enforcement. Hard caps, rate limits, and entitlements that stop a runaway agent before it costs you $200 instead of $2. For an AI product with agentic usage, that is insurance, and whether it is worth $399 depends on whether you have had a runaway bill. Most founders have. The free Build tier covers 10,000 entities and 5 million events, which covers most solo founders entirely.

The four mistakes that cost money

Metering at a granularity that charges you twice. If your underlying cost is per token and your meter is per token, you pay the meter rate on top of the compute. Meter per request, per job, or per thousand tokens, and price the unit at a multiple of your cost.

Pricing the average user when your cost curve is a cliff. The average customer is a fiction that hides your margin problem. Look at the top decile. If they are unprofitable, you have a pricing bug, not a marketing problem.

Pure pay-as-you-go with no floor. Revenue swings, and customers fear surprise bills enough that they cap their own usage and stop getting value. Every serious usage-based pricing page I have seen in 2026 uses a hybrid: a monthly base that includes an allowance, then metered usage on top. You need the base for predictability, and the metering for accuracy.

Building invoicing yourself. You will get proration wrong, mid-cycle downgrades wrong, and credit notes wrong. The proration edge cases alone will eat a week every quarter. Use a vendor for invoicing and spend your time on the product.

When to move off Stripe entirely

Honest answer: probably not soon, and probably not for pricing reasons alone.

Move off if you are reselling through cloud marketplaces and need that revenue recognized properly. Move off if you have negotiated enterprise contracts with committed volumes, minimums, and ramp schedules that flat-rate billing cannot express. Move off if you need usage data for revenue recognition under ASC 606 with real audit requirements. Move off if you are burning more than roughly $1,000 a month in billing fees and the percentage model has stopped making sense, which for most solo founders happens somewhere around $100,000 a month in revenue.

Stay on Stripe if you are under that threshold and your usage model is simple. The 0.7% pay-as-you-go rate is hard to beat, and Stripe’s dunning, invoicing, and Checkout are worth more to a one-person company than a cheaper meter would be.

What I would actually build

If I were shipping an AI product today with unknown usage patterns, I would start on Stripe Billing with a flat subscription that includes a token allowance. No metering infrastructure at all in month one. I would instrument usage in my own database, with the metering event shape I would want later already decided, so retrofitting is a query job rather than a rewrite.

Then, once I could see the real distribution, I would move to Orb or Metronome and switch the plan structure to a hybrid. If my usage is agentic and unbounded, I would put Stigg in front of everything to enforce caps, starting on the free tier and only paying if runaway usage became a real pattern.

The order matters more than the vendor. Understand the unit economics first, pick the meter second, and only then wire up invoicing. Founders who do it the other way around end up with an elegant billing system that prices their product wrong.