The next evolution of Polar

Billing was built for software with high and predictable margins. Gross and net revenue were almost the same. A customer was a person, a product was a seat, and prices rarely changed.

That's no longer true.

Every request comes with a cost

Frontier inference is leveraged behind more and more features being shipped. Margins therefore move per customer, per model and per request. Yet all billing platforms only help you track revenue when you need to be obsessing over unit economics from day one.

Teams are not all humans

Whether you sell to agents or spawn them for your customers, they operate at an order of magnitude faster than people, each needing their own metering, credits and guardrails. Latency to check any of them is now a substantial economical risk given their speed.

Billing is now in the hot path

Billing used to be integrated last and at the edge of codebases. Send customers to checkout and listen for webhooks to flip a boolean. Now usage, metering, credits and entitlements are checked across the entire codebase and make up most of the customer state. Latency and reliability has never been more important. So much so that many teams are bringing it in-house.

It's time for billing to be reimagined. So you can iterate on pricing with the same velocity and confidence as code, and leverage agents in the loop here too.

Day 1

Our team met up in Berlin late August. We called it Day 1 and explored what the future of billing should look like in a world where products are consumed by the token.

Zero Latency Metering

Uptime will always be crucial in billing, but it now needs to be fault-tolerant and local-first by design. Why?

1. Usage events yield costs, revenue and meters so they cannot be lost.
2. Entitlement and credit checks are gatekeeping features so any latency is felt by users and their agents.

We're building a local-first architecture to address these concerns and to offer zero network latency metering. You'll be able to leverage this for non-billable meters too, i.e product metrics, to track and visualize customer usage as well.

Business Guardrails

Costs are a first-class citizen in our event ingestion already, offering real-time unit economics per customer and even features through spans. Paired with zero latency metering, this will enable powerful new primitives in our SDK. We call them Signals.

Want to downgrade a customer to a cheaper model once they reach a certain threshold of credits? Or rate-limit them in case margin drops below an acceptable minimum? Easy. Just register the credit or margin condition of interest and it will trigger once those conditions are met and at runtime. IFTTT for business concerns.

Pricing as Code

Billing has always been configured in a point and click dashboard and now backed by an API, MCP & CLI. We're taking it one step further.

Pricing, plans, meters and entitlements all defined as code at the core that agents can reason about, tweak and optimize. Configuration living in your codebase next to the product they describe. Our SDK then offers type safety for business definitions too, e.g events, meters, plans.

Changes are staged to a new version. You can branch out anytime. Seeing a beautiful diff of changes across meters, entitlements, prices and plans. Right next to a simulation of those changes applied to historical data and custom assumptions. You're now one click or CLI command away from deploying a new experiment with confidence.

Of course, merchants can still choose to manage their configuration through the dashboard as before if they prefer, and still get the benefits above. Just not additional type safety and version control directly as code.

Identities

Customers are not all humans these days. You might only sell to agents, spawn them on customers' behalf or not at all. All depending on entitlements, meters and credits.

We're calling them identities whether they're human or machines. Identities can be nested, share entitlements, and delegate and propagate meters and credits between them within the nested hierarchy you design. Ensuring our SDK can offer the same powerful primitives, abstractions and guardrails regardless of which identity is the actor at runtime.

Design Partners

In September, we built a working prototype and took it to San Francisco. Showing it to startups, scale-ups and enterprises that feel the limits of today's billing the most. The response was better than we had hoped for.

We're fully locked-in and will ship this vision with high velocity across iterations. Sharing learnings, demos and more as we build with our community.

We'd love to work with more startups that are feeling the pain of billing today. So if you're struggling with meters or iterating on pricing with velocity, we'd love to work with you.