Autumn wants pricing changes to be a config edit, not a rewrite

There's a rite of passage almost every AI startup goes through, usually somewhere between launch and the first serious growth spurt. Call it the billing rewrite.

The company launches with the simplest thing that works: a $20-a-month subscription wired up through Stripe in an afternoon. Then reality arrives. A handful of power users are burning through more model tokens than their subscription price covers. The team needs usage limits. Then credits, so customers can top up. Then a free tier with a monthly allowance, an enterprise plan with custom terms, and a way to handle the customer who upgrades mid-cycle and expects proration to just work.

None of this is Stripe's fault. Stripe moves the money reliably. The problem is everything around the money: knowing which customer is on which plan, what features they can touch, how much usage they have left, and what should happen when they run out. That layer lives in your own database, gets updated by a tangle of webhook handlers, and grows edge cases faster than anyone documents them. Engineers who signed up to build an AI product end up spending weeks maintaining a billing state machine instead.

Autumn exists to make that whole layer someone else's problem. It's an open-source layer that sits between Stripe and your application, and it exposes the entire billing model through three functions: attach, check, and track. Y Combinator, which backs the company, describes it as Stripe for AI companies. It's already running in production at Mintlify, Firecrawl, and T3 Chat.

Why AI products broke the old billing playbook

For two decades, SaaS billing was boring in the best way. You charged per seat, per month. Costs were mostly fixed, margins were fat, and a customer who used the product heavily cost you barely more than one who logged in twice a quarter. A subscriptions table and a couple of webhook handlers covered it.

AI products don't work like that. Every request a customer makes has a real marginal cost, paid to a model provider in tokens. A flat subscription means your heaviest users can quietly turn negative margin, and your lightest users overpay until they churn. So AI companies have converged on more honest but far more complicated pricing: usage-based billing, prepaid credits, subscriptions with included allowances and overage charges, seat-based plans with per-seat limits, and hybrids of all of the above.

Each of those models is easy to describe and miserable to implement. Credits need balances, top-ups, and expiry. Allowances need metering and reset logic. Overages need thresholds and invoicing. Upgrades and downgrades need proration. And because nobody gets pricing right on the first try, the model you ship today is probably not the one you'll want in six months. Rewiring a hand-rolled billing system to test a new pricing structure is the kind of project that slips quarters.

That last part is the real cost. For an AI startup, pricing is not a set-and-forget decision. It's one of the main levers the company has, and the ability to experiment with it quickly is worth real money. A billing layer hard-coded around last year's pricing model takes that lever away.

Three functions instead of a state machine

Autumn's answer is to collapse the whole problem into an API small enough to hold in your head.

Attach handles every purchase flow. When a customer picks a plan, buys a credit top-up, or moves between tiers, your app calls attach. Autumn returns a Stripe Checkout URL for new purchases, or handles the upgrade or downgrade directly. One function covers the paths that usually spawn a dozen webhook handlers.

Check answers the question your app asks constantly. Can this customer use this feature right now? Do they have messages, credits, or seats remaining? Instead of joining a subscriptions table against a usage table and hoping both are current, your code calls check and gets a yes or no.

Track records usage. When a customer sends a message, runs a job, or consumes anything metered, your app calls track with the event. Autumn keeps the balance, applies it against allowances and credit packs, and knows when someone has crossed into overage.

That's the integration surface. Notably absent: webhook handling. Autumn consumes Stripe's events itself and keeps the customer's state current, so the sequencing bugs that plague hand-rolled billing code (the checkout that succeeded but didn't unlock the feature, the cancellation that never propagated) stop being your bugs. For the frontend there's a React hook that exposes customer state directly, which is enough to build paywalls, usage meters, and upgrade prompts without another API roundtrip.

The pricing model itself lives in Autumn as configuration, not in your code. Free tier with 100 messages a month, Pro at $20 with 1,000 included and overage after that, credit packs on top, custom enterprise contracts negotiated per customer: all of it is defined in Autumn, and your application keeps calling the same three functions. When the pricing changes, the code doesn't.

The system of record for who's paying for what

Beneath the checkout flows, what Autumn really takes over is a piece of state every product company has to keep somewhere: the mapping from each customer to what they've bought, what they can access, and how much they've used.

Most teams scatter that state across Stripe metadata, an entitlements table, a usage counter in Redis, and a few feature flags. Every new pricing wrinkle adds another place for those copies to disagree. Autumn's pitch is to be the single database for that mapping, purpose-built for the pricing models AI companies actually use. Subscriptions, usage-based overages, credits with top-ups, seat-based plans, add-ons, and one-off custom deals are all first-class objects rather than special cases bolted onto a subscriptions table.

Once that state has one home, the features that are usually painful become straightforward reads. A customer portal showing remaining credits is a check call. A sales rep closing an enterprise deal with nonstandard terms gets a custom plan in Autumn instead of a schema migration. Finance gets numbers that agree with what the product actually enforced.

Open source where trust matters most

Autumn is Apache-2.0 licensed, with the full platform on GitHub, where it has picked up around 2,700 stars since its Show HN launch in mid-2025. You can self-host it or use the hosted cloud.

For most product categories, open source is a distribution tactic. For billing it's closer to a requirement. This layer sits between your customers and your revenue; adopting a closed, venture-backed startup as that layer is a real risk, because if the vendor disappears, your pricing model disappears with it. Source availability changes the calculus. If Autumn the company vanished tomorrow, Autumn the software would still run, and your billing state would still be yours.

It also clarifies what Autumn is not: a Stripe replacement. Stripe remains the payment processor, the merchant of record for the money movement, the thing your accountant already understands. Autumn is the opinionated layer above it, competing not with Stripe but with the internal billing code teams write because Stripe's primitives are lower-level than their pricing model. That's a lane the incumbents have mostly left open. Enterprise billing platforms like Zuora were built for a different era and a different buyer, and metering-focused tools still leave the entitlement logic to you.

A pivot the day before demo day

Autumn comes out of Y Combinator, but by an unusual route. Founders Ayush Rodrigues and John Yeo went through the fall 2024 batch building software for banks, and pivoted the day before demo day. Autumn is what they landed on: a company built around the observation that everyone in their YC batch seemed to be writing the same billing code, badly, at the worst possible time.

Selling infrastructure to your own batchmates turns out to be a decent go-to-market. The early adopters were fellow YC companies with exactly the pricing problems Autumn targets, and the user base has since grown to hundreds of developers and startups, including companies doing multiple millions in annual revenue on Autumn-managed billing. Mintlify runs documentation infrastructure for thousands of dev-tool companies. Firecrawl sells web scraping for AI agents by the credit. T3 Chat sells a consumer AI chat subscription where every message has token costs behind it. Different businesses, different pricing models, one billing layer underneath.

That customer list matters because billing software earns trust only one way. It either computes the right number every time, or you rip it out. Companies with real revenue keeping Autumn in the money path is a stronger signal than any benchmark.

Pricing as a thing you can iterate

The standard advice to founders is that pricing is among the highest-leverage decisions they'll make, and the standard reality is that most teams change pricing about once a year, because the plumbing makes experiments expensive. The interesting promise of Autumn is what happens when that constraint goes away.

A team that can reprice in a config change instead of a migration can treat pricing the way it treats the product: ship, measure, adjust. Test a credit pack against an overage model. Give one cohort a bigger free allowance and watch conversion. Close the enterprise deal with weird terms without asking engineering for a favor. None of that is revolutionary in theory. It's just been gated behind billing code nobody wants to touch.

AI made pricing harder at the exact moment it made shipping software easier, and every team that noticed has felt the imbalance: a weekend to build the feature, a month to bill for it correctly. Autumn's bet is that the gap closes the same way most infrastructure gaps close, with a layer good enough that rebuilding it yourself stops being a serious option. Three functions in, one rewrite you never have to do.