Do things that really scale

By Khaleel Al-Adhami at August 4, 2025.

In Paul Graham's 2013 article titled "Do Things that Don't Scale", he outlines what he believes to be the ideal user-acquisition strategy for early-stage startups. I largely agree with the points he raised, and I would like to draw an orthogonal argument. To build open source tools that are aimed at serving the public, build the most scalable thing you can imagine.

I found that lots of modern tech businesses rely on a rather thin technical moat. One example is Uber, where the codebase for a similar basic service is possible to implement in a month or two. The moat in Uber's case is its userbase, both riders and drivers. If you would like to challenge Uber (and someone probably should), then you must do so in a way that does not require you to have a thousand employees to do so.

This is difficult, obviously. Although there are some success stories that we can draw from. During college, basically every club and group of friends used when2meet, a service that allows people to indicate their availability in the future. It is so simple, in fact, that it did not need a single update in the past ten years. How can it scale this well? Well, there is so little to scale:

1. There are no user accounts. Once an event is made it cannot be changed; it is referenced through a permanent link.
2. It stores minimal information. For each event, it has a title and the times when it is possible to select. Once people fill the event, for each it stores user, an event-specific password (because there are no user accounts), and the times they selected. An average event would not exceed a kilobyte.

These can be leveraged by the user to avoid hard-to-scale features. The website does not have real-time updates. To update the information, just refresh the page. To store the random when2meet link, you can assume the user will paste it in a group chat.

I have seen an increasing number of websites that use web assembly to do heavy computation on the user device. This makes it possible to build tools like cobalt, which uses libav.js that is basically ffmpeg and more in your browser. Moving this computation to the user device allows the server to be significantly lighter and much more scalable.

Building open-source alternatives to proprietary tools often requires breaking certain assumptions that we hold about how tools ought to be built. It is not enough to make your open-source tools self-hostable, but make them scalable enough so you can offer them yourself for free.