A solution to Stripe’s painful DX

If you’re on tech twitter you may have noticed an increasing dissent with Stripe and it’s DX. t3.gg (Theo) summarizes it best:

“IMO, the biggest issue with Stripe is the "split brain" it inherently introduces to your code base. When a customer checks out, the "state of the purchase" is in Stripe. You're then expected to track the purchase in your own database via webhooks.

There are over 258 event types. They all have different amounts of data. The order you get them is not guaranteed. None of them should be trusted. It's far too easy to have a payment be failed in stripe and "subscribed" in your app.”

Autumn makes this 1 line of code—the key is a layer over Stripe which controls which of your users can access features and how much of them (for usage-based components). Here’s how it works.

In our UI:

1. Define the features that need to be gated based on pricing (eg access to ‘Pro Analytics’ and ‘Number of Seats’).
2. Package these into plans (eg free tier has only 1 seat, Pro tier has Pro Analytics and 5 Seats), and set the pricing.

From your application:

1. Just call our attachProduct() function and specify the product name and customer. If the customer needs to make a payment, a checkout link is returned. Otherwise, all subscription and upgrade/downgrade logic is taken care of.
2. In your features code, use entitled() to determine whether a user has access to the feature or not

We’re currently in open-beta and are working with some awesome YC companies to take this headache off their plates. We see it similar to what Clerk did for Auth.

Next on the roadmap are embeddable UI components to handle pricing pages and paywalls out-of-the-box. Would love for you to check out our product/docs and give us your feedback!