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.