←back to thread

139 points ayushrodrigues | 4 comments | | HN request time: 0s | source

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!

1. satvikpendem ◴[] No.44371541[source]
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.
replies(1): >>44371656 #
2. ayushrodrigues ◴[] No.44371656[source]
Adapty looks cool! Kind of similar to Revenuecat?

I think the offering is similar -- both manage entitlements and paywalls. And while we do have a proportion of users that use us for mobile apps we're pretty focused on SaaS / web.

I can imagine Adapty would go deeper on features like AB testing, paywall designing etc

Our users handle lower volume of subscriptions but require more flexibility and depth on the pricing models they want to support.

replies(1): >>44372001 #
3. satvikpendem ◴[] No.44372001[source]
Yep a RevenueCat competitor essentially. Makes sense to focus on web, seems like it's using pure TypeScript, is it mainly for the backend, or for the frontend?
replies(1): >>44372024 #
4. ayushrodrigues ◴[] No.44372024{3}[source]
We have react hooks so we try and make the majority of the integration lift on the frontend. One of our contributors is helping us launch a python SDK soon too !