Korva is a scroll of the internet’s best ideas.
Slay your biggest dragon first
Scalability was the obsession
In the early 2000s, scalability was an obsession. Servers were slow and bandwidth was slim, so a site that could only serve 10,000 or 100,000 people crashed. A scalable business model meant one that doesn't top out at a small amount of money. A founder without good answers on how a product scaled was not considered fundable.
The essay that flipped it
In 2013, Paul Graham wrote an essay titled "Do Things That Don't Scale" to invert that. Plenty of startups build something beautiful with a big team, all the servers set up, and a chief architect in place, and no one wants it. Users churn and it's game over.
Worry about the biggest problem at any one point in time and slay that dragon before the later ones. For most startups it's getting from zero to one: a first customer and a first product, with no need to think about scalability yet. Once people want the product enough, there is the luxury of worrying about scaling, and then it's time to scale.
Why was scalability an obsession in the early 2000s?
In 1999, programmer Dan Kegel published a page describing the C10K problem: how to make a single server handle ten thousand connections at once. Hardware was costly and web servers were not built for that load. Sites that became popular overnight could crash, which made handling traffic a core engineering concern.
What did Airbnb's founders do by hand at the start?
Paul Graham's essay Do Things That Don't Scale describes Airbnb's founders going door to door in New York to meet their hosts. They photographed listings themselves to improve how the apartments looked on the site. The essay offers this as an example of a company recruiting early users one at a time.
Why do so many startups fail from lack of users?
CB Insights reviewed post-mortems written by failed startups and found that lack of market need was the most commonly cited reason. Running out of cash and being outcompeted followed it. Building a product no one wants uses up a team's time and money before it can learn what people actually need.