Autumn Handles the Billing Code You Keep Putting Off

The Macro: AI Billing Is Its Own Special Mess

I have built billing systems. I do not recommend it. The standard advice is “just use Stripe,” and Stripe is great, but Stripe is a payment processor. It handles charges and subscriptions. It does not handle the logic layer that sits between your product and those charges. That logic layer is where things get ugly.

For most SaaS companies, billing is annoying but manageable. You have three tiers, maybe an annual discount, and you wire up some webhooks. For AI companies, billing is a full-time engineering problem. You have usage-based pricing because your costs scale with inference. You have credit systems because customers want to prepay for tokens or API calls. You have rate limits tied to plan tiers. You have overages. You have rollover balances. You might have all of these at once, for different customer segments, on different pricing models.

The result is that every AI startup ends up building a custom billing backend. It takes weeks or months. It touches the database, the API layer, the frontend, the webhook handlers. And then the pricing changes, because pricing always changes, and you get to do it again.

This is not a hypothetical problem. Ask any engineer at an AI company what they dread most about a pricing model change, and they will describe a multi-sprint project involving database migrations, webhook rewiring, and edge cases that only surface in production. The cost in engineering hours is real and it compounds over time.

The existing options are limited. Stripe Billing handles subscriptions but not usage tracking or credit ledgers natively. Lago is open-source and usage-focused but requires significant setup. Orb is polished but expensive and closed-source. Chargebee and Recurly are built for traditional SaaS, not AI workloads with variable costs per request. None of these were designed from the ground up for the specific billing patterns that AI products need.

The Micro: A Billing Layer That Gets AI Pricing Right

Autumn was founded by Ayush Rodrigues and John Yeo. Ayush was previously a PM at Checkout.com, which means he spent years watching developers fight with payment infrastructure. John is a software engineer with six years of experience and an Imperial College London engineering background. They came through Y Combinator’s Summer 2025 batch as a two-person team based in London.

The product sits between your application and Stripe. You model your pricing plans in Autumn’s dashboard. You send usage events to Autumn’s API. Autumn handles the math: tracking consumption, managing credit balances, gating features, processing overages, and syncing everything back to Stripe for actual payment collection. Your application asks Autumn “can this customer use this feature?” and gets back a yes or no. That is the core interaction.

What makes this interesting is the range of pricing models it supports natively. Usage-based billing where you charge per API call or per token. Credit systems where customers buy a block of credits and draw them down. Hybrid plans with a base subscription plus overage charges. Rollovers that carry unused credits forward. Enterprise custom pricing that does not fit any template. All of these patterns live in Autumn’s configuration layer instead of in your codebase.

The open-source angle matters here. Billing is sensitive infrastructure. Companies are understandably cautious about routing revenue logic through a black box, especially a startup’s black box. Being able to read the source, self-host if needed, and understand exactly how credit deductions or rate limits are calculated removes a meaningful objection.

They say hundreds of developers are already using it in production, with YC companies processing millions in transactions through the platform. Those are strong early signals for infrastructure tooling, where trust and reliability matter more than slick marketing.

The developer experience looks clean from what I can see. A few lines of code to check feature access. Event-based usage tracking. A dashboard for non-engineers to manage pricing without touching code. This is the kind of separation of concerns that billing has needed for a while.

The Verdict

I think Autumn is solving a real problem in the right way. Every AI company I know has either built billing infrastructure they hate maintaining or is currently planning to build billing infrastructure they will hate maintaining. A dedicated layer that handles the AI-specific complexity of usage tracking, credits, and feature gating on top of Stripe’s payment processing is the correct architecture.

In 30 days I want to see how the migration story works. Getting new projects onto Autumn is presumably straightforward. Moving an existing billing system over is where things get complicated, and that is the more common real-world scenario.

In 60 days the question is how the pricing and packaging of Autumn itself shapes up. Infrastructure tools for billing have to price themselves carefully. Too expensive and teams just build in-house. Too cheap and the business does not sustain the support burden that billing infrastructure demands.

In 90 days I want to understand the failure modes. What happens when Autumn is down? What happens when a usage event gets dropped? Billing infrastructure that works 99% of the time is billing infrastructure that generates support tickets, disputes, and lost revenue the other 1%. The answer to “what does your system do when something goes wrong” tells you more about billing tooling than any feature list.

The open-source model, the Stripe-native architecture, and the founders’ payments background all point in the right direction. If you are building an AI product and you are about to start writing billing code, I would look at Autumn before you write the first line.