alt Hacker NewsShow HN: Autumn – Open-source infra over Stripe
Hey HN, I’m Ayush from Autumn (https://useautumn.com/). Autumn is an open source layer over Stripe that decouples pricing and billing logic from your application. We let you efficiently manage pricing plans, feature permissions, and payments, regardless of the pricing model being used. It’s a bit like if Supabase and Stripe had a baby.
Typically, you have to write code to handle checkouts, upgrades/downgrades, failed payments, then receive webhooks to provision features, reset usage limits etc. We abstract this into one function call for all payments flows (checkouts, upgrades, downgrades etc), one function to record usage (so we can track usage limits), and a customer state React hook you can access from your frontend (to handle paywalls, display usage data etc).
Here’s a demo: https://www.youtube.com/watch?v=SFARthC7JXc
Stripe’s great! But there are 2 main reasons people use Autumn over a direct Stripe setup:
(1) Billing infra can get complex. After payments, there’s still handling webhooks, permission management, metering, usage resets, and connecting them all to upgrade, downgrade, cancellation and failed payments states.
(2) Growing companies iterate on pricing often: raising prices, experimenting with credits or charging for new features, etc. We save you from having to handle usage-based limits (super common in pricing today), rebuilding in-app flows, DB migrations, internal dashboards for custom pricing, and grandfathering users on different pricing.
Ripping out billing flows etc, really sucks. With Autumn, you just make pricing changes in our UI and it all auto-updates. We have a shadcn/ui component library that helps with this.
Because we support a lot of different pricing models (subscriptions, usage, credits, seat based etc), we have to handle a lot of different scenarios and cases under the hood. We try to keep setup simple while maintaining flexibility of a native integration. Here’s a little snippet of the architecture of our main endpoint: https://useautumn.com/blog/attach
Currently, the users who get the most value out of us are founders that need to move fast and keep things flexible, but also new/non-technical devs that are more AI native.
You can clone the project and explore the repo, or try it out at https://useautumn.com/, where it’s free for builders. Our repo is https://github.com/useautumn/autumn, docs are at https://docs.useautumn.com/ and demo at https://www.youtube.com/watch?v=SFARthC7JXc
We’d love to hear your feedback and how we could make it better!
Comments
What's the plan for monetization? Your license is Apache 2.0, which I'm not sure makes sense from having customers pay.
In contrast, Lago uses AGPL-3.0 and has an open-core model (not sure if the premium features are source available or not), which makes it more clearer on how they're going to make money.
Hi, your docs say that users don't need state syncing, but when using Stripe you do need state syncing or to ingest the Stripe events. I also don't see any information in the docs about handling e.g. chargebacks or other events and listening for (or otherwise syncing against the history of) those events. I'm a little confused - why would I want to not have that? I could be misunderstanding this project though!
Sounds a lot like https://priceops.org/ , but Tier (Show HN: Tier.run – Terraform for Stripe https://news.ycombinator.com/item?id=33429972 ) seems to have shut down.
Any insight into why they failed and why you will be different?
Neat! Seems similar to Lago (also open source): https://www.getlago.com/
Are you planning on adding other payment providers besides Stripe?
its so crazy to see so many new tools launching because integrating stripe is that hard. nice demo
few builders i know struggling with this. will share this with them.
love this as someone who's been fixing the same billing bugs over and over and who sometimes finds stripe more complex than it should be. will make sure to try this on my next adventure.
btw, if you still want to go directly with stripe, here are some general recommendations/notes I generally agree with:
Nice to see this show HN, I was literally talking to a friend yesterday about how Autumn is making their billing way easier.
I've suffered so much with all the pricing changes I've been experimenting with (early stage solo founder). Till now had been chugging along doing it manually but I'm going to integrate autumn soon.
Currently implementing billing/usage for Nango, I wish I had a solution that simple to do it. Would have saved us at least a week.
Will this work for a charity? One-time and regular (monthyly, daily etc) donations? Thanks
How is update credit card on file and a listing of past invoices handled?
this is interesting and i've been poking at autumn for a little bit. and nice to see more billing in the oss. we started on a self hosted billing solution, but quickly realized that a single centralized (hosted) model was better for our particular use case (less to manage). curious if you're seeing the oss as a driver for trust or if folks are demanding this for some reason?
also a fan of a single state for billing, metering, and entitlements. any plans for a go sdk for these?
crazy how hard it is to integrate stripe
Congrats on the release Ayush! Happy to see this come to market.
I have some web/mobile apps and I'm currently using Adapty which has custom paywalls and other sorts of features, as well as web-based paywalls now that Apple lost their ruling against Epic Games (and I'm using Flutter but the UI side doesn't necessarily matter due to the web-based nature of the paywalls). Is this a use case you are targeting? Adapty also integrates with Stripe for the web side of its offerings.
Feels good to have billing solved in these rapid shipping times
looks awesome, but how much can it scale up? i need to handle alot of throughput for my startup, like events per second
Looks cool, but usually permissions management is done by auth, how does this work with autumn?
[dead]
From what I could gather from quick look this seems to targeted towards B2C applications, i.e. 1 customer has 1 user. In B2B cases there is often cases with "customer has entitlement to feature X, but only users A & B can use it, C cannot" (and in some cases users have access to multiple customers). Are you planning on adding this kind of support and are you planning on handling the role/user mapping yourself or just providing some integration points?
(just to be clear, not relevant in my case at this point, just something that was a bit messy to handle in something I worked with previously)