On the evening of 25 February 2025 I went to the Cloudflare Founders & Developers Meetup at Wicked Grounds on Generaal Vetterstraat in Amsterdam. The invitation promised a look at developer trends and challenges for 2025, a customer case and a walking dinner. It was also the start of a busy week, with DevWorld Conference at the RAI two days later.
This is a throwback post built from the photos I took that evening. Two talks made it onto my camera roll: one from Cloudflare on building with Workers, and one on why so much modern software is slow.
A full room at Wicked Grounds, with Cloudflare lanyards on almost every chair.
”Go build cool BIG stuff!”
The first slide I photographed was Cloudflare’s, with the title “Go build cool BIG stuff!”: “cool” crossed out and replaced with “BIG”. The speaker on the slide was Rob Sutter, and the audience was applauding when I took the picture.
Rob Sutter on stage with the resources slide. I’ve blurred the contact details.
The slide listed the resources behind the talk:
- Workers Analytics Engine
- Workers Gradual Deployments
- Workers Observability
- Workers Runtime (workerd on GitHub)
- Hono.js
- Zod
My take: that list says a lot about where Workers has gone. Analytics, gradual rollouts and observability are what you need once a platform runs real production traffic, not weekend demos. And because the runtime is open source as workerd, you can see how it works instead of treating it as a black box.
Software is slower than it needs to be
The second talk, by a different speaker, was the one I photographed most. It opened with this comparison:
- Slow software in the 90s was maybe 70% slower than the theoretical hardware limit.
- Now it’s 1000x to 10000x slower.
The opening slide: the gap between hardware and software has grown by orders of magnitude.
Next came a list of causes. Most platform teams will know them:
- Too many SaaS tools, where the overhead of the solution is larger than the problem
- Over-specialisation of services: “the micro service hype”
- Premature “future proofing”
- Relying too much on third-party libraries (dependency hell)
- Containerisation complexity
- Network and serialisation overhead from overly distributed systems
- Selecting the wrong tools for the job
- Systems that are hard to debug: black boxes, sheer size, abstract code
The list of causes. It ends with “Etc etc”.
Even the popular tools pay a price
The speaker then went through well-known tools and the trade-offs behind each one:
- Redis: “blazingly fast”, but all commands are in a string format for readability
- PostgreSQL: its focus on plugins, even for internals, is great for extensibility but makes it very hard to get all the performance the hardware can give
- Nginx: great to configure, but adds significant overhead by calling and checking the configuration on each request
- ChatGPT: so expensive to run that it’s unusable for a lot of real use cases
- Next.js: easy to start with, but adds a lot of overhead (50x over the Node.js http module)
Every tool on the list is popular for good reasons, and each one has a cost.
Left: a small code change that “runs 15x faster than the original”. Right: examples of teams that built lean.
The code slide made the point at the smallest scale. A React useMemo that rebuilt a filtered object with Object.fromEntries and Object.entries(...).filter(...) was replaced with a plain for loop over the disabled fields, which copies the object only when it has to. The slide said the new version runs 15x faster and “requires less knowledge of the library”.
The examples slide went the other way and showed what lean engineering can achieve:
- WhatsApp scaled to a billion users with 30 employees
- Cloudflare implemented zstd for shared compression, replaced Nginx with Pingora, and built its own runtime for Workers and its own key-value store that runs faster than Redis, “and more (!)”
- FFmpeg: a one-man job outperformed all existing encoding and decoding
- uWS: an HTTP network layer in C++, interoperable with Node.js and an order of magnitude faster
- esbuild: written in Go, it replaced webpack and made JavaScript bundling much faster
- Figma: a custom render engine that changed the way people design and work in files
- DeepSeek: R1 API costs are 20 to 40x cheaper than o1-mini
The practical advice, on the slide behind me in the opening photo: when you select a tool, make the effort to run a benchmark that simulates what you need it for. It shows bottlenecks fast and postpones the need to scale or replace tools later.
My takeaways
- Complexity has a runtime cost, not just a maintenance cost. Every extra network hop, serialisation step and SaaS integration shows up in latency and in the bill.
- Benchmark your real workload before you commit. My take: a short benchmark that matches your own traffic pattern tells you more than any feature matrix.
- Lean is a choice. Most of the examples on that slide came from small teams that decided to own a critical layer instead of stacking abstractions on top of it.
On the way out, a table card listed where to meet Cloudflare next: Dev World Amsterdam (27–28 February, the RAI) and AWS Summit Amsterdam (16 April, the RAI).
