Open source payments and billing infrastructure

Hey! Flowglad founder here. I threw that README together really quickly, and was hoping to spruce it up before we'd do a show HN - but HN found us first. I totally agree it could be clearer.

Our goal is to maximize how much mileage you get per unit effort spent on payments + billing.

We have two levers to do this: 1) reduce effort and 2) increase mileage.

For the effort part, we're starting by shrinking the integration footprint and abstracting away the need to think about webhooks or model billing data in your database. Those should make it easier to get set up than other alternatives.

We're working on a lot of stuff to increase mileage. Today if you want to update how you price your product, or support multiple different pricing regimes (e.g. standard self service for smaller customers + and bespoke terms for larger customers) it can get messy pretty quickly. Managing how you gate feature access, keeping track of old customers on legacy pricing vs new ones on new pricing, putting together pricing tables, etc. And then dealing with all of this every time you want to try out new pricing. We're working on a bunch of features to make this easier, including embeddable billing UI that connects to your customers' billing state.

As for AI, all I can comment on is what I've seen:

1) On new programmers: anecdotally I've talked with about a dozen or so people who are non-technical and are launching their first paid SaaS products after prompting v1s into existence with Lovable/Cursor/Bolt. Last week, I coworked with one of them, a friend. I saw firsthand how hard it was for her to set up even straightforward payments. Some of that is being new to programming, and some is just AI having a harder time reasoning about distributed systems. If you can build a more approachable devex that abstracts this away, more people will be able to monetize the products they build with less effort.

2) On startup billing: my founder friends building in AI are all hitting much more complex billing scenarios around usage, monthly meter allocations, measuring overage, etc. Many AI products simply want to be priced on usage, and usage has more complexity than the standard monthly SaaS subscription.

And the first $1,000 you process every month are at-cost, 0% surcharge.

For comparison, Stripe's Billing productcomes with a .7% surcharge on top of their standard processing fees.

I've been somewhat surprised since starting Flowglad by the number of founders and devs who aren't aware of this.

Vibe coding has been such a full behavior change that people are vibe coding even sensitive mission-critical parts of their app, like payments. Which, I agree, means a lot more can go wrong.

We're building an SDK that makes it easier vibe code payments correctly.