Open source payments and billing infrastructure(github.com)
github.com
Open source payments and billing infrastructure
https://github.com/flowglad/flowglad
3 comments
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.
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.
Layered over Stripe, 1% surcharge.
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.
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.
Mixing payments gateways and vibe coding. What can go wrong?
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.
We're building an SDK that makes it easier vibe code payments correctly.
These two things are unrelated, and while I'm skeptical about the first point (do more people program solely due to AI?), startup billing hasn't become more complex because of AI, and to be honest if you're just doing small scale sales to consumers (B2C), getting set up is not that challenging with the big providers like Stripe. It takes a bit of work, yes, but it's not really that challenging even if you have to manage multiple subscriptions.
There are other things I could point out (is it common that products need to support multiple payment processors?), and while I'm not trying to be completely negative about this project because it's commendable to try to make it easier for small teams to be able to accept payments, the reality is that it's difficult for multiple reasons (e.g. KYC) and this shouldn't be fully hidden from the developer that deals with billing. You can't get away from the complexity just by making an abstraction layer and when the abstraction fails the "vibes coding" will hit a brick wall.