One thing to keep in mind when judging what's 'appropriate' is that Cloudflare was effectively responding to an ongoing security incident outside of their control (the React Server RCE vulnerability). Part of Cloudlfare's value proposition is being quick to react to such threats. That changes the equation a bit: any hour you wait longer to deploy, your customers are actively getting hacked through a known high-severity vulnerability.
In this case it's not just a matter of 'hold back for another day to make sure it's done right', like when adding a new feature to a normal SaaS application. In Cloudflare's case moving slower also comes with a real cost.
That isn't to say it didn't work out badly this time, just that the calculation is a bit different.
These engineering insights were not worth the 16 seconds load time this website took.
It's extremely easy, and correspondingly valueless, to ask all kinds of "hard questions" about a system 24h after it had a huge incident. The hard part is doing this appropriately for every part of the system before something happens, while maintaining the other equally rightful goals of the organizations (such as cost-efficiency, product experience, performance, etc.). There's little evidence that suggests Cloudflare isn't doing that, and their track record is definitely good for their scale.
It's not even clear that the premise is true. There's lots of 'research' done in the big tech companies.
The biggest reason why companies don't seek to emulate "Dupont, Bell Labs, IBM, AT&T, Xerox, Kodak, GE", is probably that it reads like a list of textbox examples of "companies that failed to execute on their research findings", so clearly there was something wrong with this approach.
From "framework fatigue" to "new framework" in five paragraphs.
Personally, I find all these minimalist, back-to-the-basics frameworks a bit misguided. It's always reeks a bit of "well my farts don't smell" – other developers' frameworks are bloated, dependency-overloaded and too complex. My new framework is simple, based on a powerful idea, and just right.
Imo, the best way to build a truly good web app in 2025 is to embrace both server-side rendering and client-side rendering, by sharing the same rendering logic between client and server, like e.g. SvelteKit, Next.js and others do.
- no company generates revenue in its first second. Even if you start a lemonade stand tomorrow, you'll have to buy some lemons first. The time-to-revenue might be very short, but it's never zero. Therefore, making no revenue for 1 day or for 10 years is not a step change, but simply a point on a curve.
- Capitalism is basically a long history of creating vehicles with increasing sophistication to bridge that gap: provide funding for ventures that have returns in the future. This is intrinsically difficult, and it's easy to waste money, but it can work immensely. This started with the Dutch inventing limited liability corporations to fund ship expeditions, and today's VC is essentially an extension of that.
- It has worked well in the past to bet on companies that don't optimize for time-to-revenue, but something else – famous examples being e.g. Amazon, Google, Meta, who all lost lots of money initially.
Hence there can be companies that make no money for quite a while. And it can even turn out that the vast majority of the companies that make no money for a while never make any money. Accepting this risk is a feature, not a bug.
Well, for reasons stated I don't believe it was a fair and representative sample then, and that 4% is closer to the upper bound than the lower. Also no idea how "no one was able to give a precise figure" – go into stripe dashboard, open most recent invoice, divide amount paid through payments processed (which are both stated right there on the invoice!)
I'm a B2B SaaS founder and paid 2.7% to stripe last month. OP, feel free to update post with new lower bound.
Thanks for the reply! I just couldn't follow how you end up paying 8% to stripe, save some very non-standard requirements or setup. You can relieve my concerns by telling me the stripe product setup that results in a $100k MRR SaaS company to pay $8k per month to stripe. Might very well be that I'm overlooking something!
Otherwise, the "no one knows exactly how much but up to 8%" framing reads like FUD to me.
Even including those, I don't see how you would get to 8%. Apart from the fact that 'Stripe Identity' isn't something I'd expect a standard SaaS company to need (or a tool like Lago to provide), the cost simply isn't that high. Radar and Sigma together for 1,000 monthly transactions adds like ~$130 to your monthly bill.
I challenge the authors of this blog post to provide me a Stripe product setup that would result in an $8,000 monthly cost for a $100,000 MRR SaaS company. It must be very unusual.
Is it really though? It very much depends on your definition of 'scaled up'. Sure, you wouldn't run a Fortune 500's payment processing through stripe's public pricing plan.
But for a $10M SaaS startup, this would come to $350k/yr (assuming some amount of non-credit-card and non-taxed payments). I would say at least 60% of that you would pay anyway to other payments processors, even doing all the software stack yourself (nothing is free in the world of finance, after all). So that leaves you with $140k p.a. for a software stack that covers billing UI, invoicing, taxes, financial reporting. It's far from obvious how you can come up with a comparable solution yourself with a budget of at most 0.5 developers and 0.5 designers that your $140k would get you.
You are right, and I see how that would push up the bill as % of revenue.
That being said, this has nothing to do with stripe's software platform which this article focuses on, and all to do with credit card payment fees. Braintree charges "2.59% + $.49 per transaction". PayPal charges "3.49% + $.49 per transaction". Square payments charges "2.9% + $.30 per transaction".
Working at a company that is currently making this decision, I appreciate the blog post. That being said, I absolutely don't see how they arrive at their numbers. They state that SaaS founders routinely pay "4-8% of revenue" to stripe. Then their own calculation ends up at 4.2% of revenue using a combination of all Stripe services possible (Billing, Payments, Tax, Data Pipeline). Where are the other ~4% supposed to come from?
If anything, the calculation is overstating the realistically expected cost in a few ways:
- Particularly B2B SaaS will likely have some % of invoice/bank transfer payment. Assuming 100% payment via credit card is a 'worst-case' assessment.
- Even given that, the bulk of the cost are credit card processing fees, which you would pay either way. Maybe not exactly at stripe's rate, but something similar.
- Stripe Tax for example doesn't charge 0.5% of revenue flat. It only charges for revenue where you’re registered to collect taxes, which for an international business will be far from every transaction (depends on locality & customer base, of course). In addition to that, the pricing drops to 0.4% if you process more than $50k per month.
All in all, I appreciate the effort, but given that Lago is a stripe competitor, this calculation dressed up as a 'neutral assessment' on Github seems disingenuous and makes me trust them less.