Experiment With Non-Scalable Changes

The obsession with scale can kill startups before they have anything worth scaling. This lesson from Airbnb's early days reveals why sometimes the best solution is the one that doesn't scale at all.

If you are stuck drowning in too much data and too many options and are dazzled by all the possibilities of code, here's a helpful bit of advice from Airbnb's rags to riches origin story: it's okay to do things that don't scale.

This advice runs counter to everything Silicon Valley preaches. We're taught to think in systems, to build for millions of users from day one, to automate everything. But sometimes the manual, unscalable approach is exactly what you need to break through.

In Airbnb's case they noticed people weren't booking rooms because the pictures sucked. So they flew to New York and shot some beautiful images. This is a very non-scalable and non-technical solution. Yet it was the turning point for Airbnb and sparked their climb out of the "trough of sorrow."

This story is perfect because it shows how wrong our instincts can be. The founders could have built sophisticated photo upload tools, automated image enhancement, or marketplace rating systems. Instead, they grabbed a camera and went to New York.

The technical mind immediately objects: "But you can't fly to every city to take photos for every host!" And that's exactly right. You can't scale that approach. But you don't need to scale it ... you need to learn from it.

Previously they had been limited by the Silicon Valley idea that every feature had to be scalable. Not every solution can be found behind a computer screen.

The scalable solution came later, after they understood what made listings successful. Once they knew that photo quality was crucial, they could build systems to encourage better photos, provide guidelines, or even connect hosts with local photographers. But first, they had to prove the hypothesis.

A corollary is the idea of paying attention to and learning from what your users are actually doing and let that lead you without out that annoying voice in your head second guessing you, yelling but that will never scale! Worry about building something good, then worry about making it scale.

This reframes the entire startup process. Instead of building scalable systems for unknown problems, you do unscalable things to discover the real problems. Then you build scalable solutions for problems you know are important.

The "that will never scale" voice in your head is often right about the tactics but wrong about the strategy. Flying to New York to take photos doesn't scale, but understanding what drives bookings absolutely does.

I've seen teams spend months building elegant, scalable solutions to problems that turned out not to matter. Meanwhile, the teams that succeed often start with brute force approaches that would horrify a systems architect but teach them what actually works.

The key insight is that premature optimization isn't just inefficient—it's a form of procrastination. It lets you avoid the hard work of figuring out what people actually want. It's easier to build scalable systems than to validate that anyone cares about your product.

Do things that don't scale. Learn what works. Then scale the things that matter.