Do Things that Don't Scale (2013)
paulgraham.comIt's so hard to put your finger on why exactly this strategy is so important. To illustrate this, consider these two options:
1. Your business needs to accomplish X. X is a manual task right now. It could take you 80% of your available time, but you would learn the ins and outs of your business.
2. The alternative is to hire someone to do X. Perhaps you could even find someone who is a specialist at X and much better at it than you are. Or you could perhaps focus on postponing X until you've written enough code that you can automate it.
Prior to PG's essay, the logical thing would have been to recommend the second approach. But today, most HN readers would agree - myself included - that the first approach is the right one. The best explanation I can offer is that building a startup is invariably a learning process, and doing X yourself forces the founder(s) to go through that process early on when the course corrections are cheaper.
I find it hard to believe how leaders still opt for #2. Their rationale is time-to-market. #2 is still fine if you "eat your own dog food". Doing it teaches a lot about how users would use the product.
In my experience this is the single best essay on how to get to product/market fit as a startup. Short read, great examples, killer recommendations. I use it as the starter point for startups and innovation departments that I work with.
I am living through this right now and have asked this questions on several forums because when you're really in the midst of this hustle you start to question your priorities and constantly get this feeling about if there is a better way. This is a counter-intuitive advice on building a product and a company but the other option would be to get lucky.
Couple of more examples about doing things which don't scale:
Instacart manually built their product catalog for the first few million products.[0]
Pandora analyzing 10,000 songs manually for recommendation. [1]
One thing that isn't captured nowadays is that a lot of what "couldn't scale" before - i.e manual work, the type of which you described - is now much more scalable due to how much easier it is to automate tasks at scale.
It's suddenly feasible to build businesses that require at-scale manual operations, because you can do so in a predictable, revenue-positive way.
"Do Things That Don't Scale" is not a choice which founders make even if they have all the resources and technical chops. If you don't know or unsure what to focus on then how do you decide to optimize and improve it?
Take Instacart for example, what would you have done differently to build the catalog given you had same information what Apoorva had at that time? Same for Pandora & Airbnb...
Having a small experience of this with a hobby project (an AI-powered chat bot). First versions, for each bot, I just cloned the repo and did a new deploy. That's finally become unworkable, so now I'm converting the project so that one server can handle many bots.
Getting to punt on all that overhead definitely helped the initial "launch", and IMO the code quality. It's proving incredibly easy to switch it over, and I think a lot of that is coming from how polished I was able to make the core of it.
Reminds me of Factorio: First you spaghetti (shitty probe project), then you mainbus (vertical scaling, haha), then you city block (horizontal scaling).
So... while I respect avoiding shameless self-promotion, referencing your hobby project, or at least including it in your "About" info would be cool, for those interested. :)
Oh! Totes fair. It's https://www.brian.bot/ and also all the help kiosks in https://topia.io/
I like this essay. Another take on "do things that don't scale" is in the technical sense that, this is evidence you are actually solving a hard problem. If you limit yourself to only things where the tools to make it wildly successful at scale already exist then you're flattering yourself a lot to think nobody every thought of that before and the world is just waiting for you to create it. It is much more reassuring to know that there are hard real world reasons why this problem isn't solved yet and you will differentiate yourself by solving them because you actually have some unique advantage, knowledge etc.
I think the important thing highlighted in this article is that a startup needs to do whatever it can to survive - which means its okay to quickly do things that won't be sustainable later. A startup needs to hit the ground running, whether that means building a quick MVP or taking to the road for users. If it doesn't build a stable position to start off from or focuses too much on planning/scaling then it won't ever be able to move from square 1. When the startup gains traction and critical mass, then it can start thinking about scaling and long-term performance.
I wonder whether there are any examples not within the startup world but building your own personal “brand” (for want of another word), or competitive edge if that works better.
> "Right then, give me your laptop" and set them up on the spot.
This article just makes me miss the pre-pandemic times when touching someone else's laptop didn't feel like a huge health violation.
> things that don't scale
Some things that don't scale (i.e. super personal interactions) do have non-linear returns. An email blast can hit 1000 users. But talking to 10 people can generate recommendations. Which hold way more value than marketing emails.
I launched a product earlier this year and it has been much harder to get this level of personal interaction over email / digital platforms. It's a lot easier to ignore an email than someone in the same room.
Very excited to return to a world of human > human interactions.
There are things that don't scale that you can still do its more given as an example.
Like for instance Groupon was prototyped in Wordpress. I believe Mailchimp would send their customers actual physical letters. Stripe would send you card readers for free.
It is better to validate the idea before writing a line of code if you can do it.
Did you mean Square instead of Stripe or does Stripe have a consumer facing side I wasn’t aware of?
It's Square that sent the card readers for free, not Stripe.
Still will send you a card reader for free, as a matter of fact, but only the magstripe-only ones. You have to pay for readers that do chips or any of their more advanced hardware.
Nothing beats human to human in person interaction, nothing.
Totally. And this is why I think all this "move to the suburbs" business is overblown.
Physical proximity still matters a hell of a lot. Especially on the margins when making something 1% easier is the difference between doing and not doing something.
Ironically pg is the guy who said the real world is really high bandwidth (Cities and Ambition) and that going where you have an audience is important. I share your frustrations about it being difficult to get to people to pitch them. Doubly when you aren't chasing an audience that spends all day in front of a screen.
The wisdom of the article aside, pg's web page seems ripe for a redesign...it's odd to see the line widths being so narrow in the era of wide HD monitors
I see a pattern:
- Someone writes an article with a catchy title.
- Someone [semi or quite] influential notices, and says: "Hey, let's write an article from the opposing perspective, to be contrarian, and see if we can also make some good points."
- Me: [Doesn't click and] thinks "Would ya look at that? An article/author which is contrarian probably just to be contratian. I'm gonna find something else to read..."
Even so, intentionally trying to be being a contrarian is a good way for industry to avoid groupthink and cargo culting. It's really valuable. I'm sure somebody will write an article called "Do Things That Scale" soon.
Oh, they definitely wrote those articles, over and over again. Google is lousy with, "Paul Graham was wrong" articles, he tends to attract that kind of attention, given the way he writes (personal, about his experience, sometimes mistaken for "this is always right").
I think you might have been downvoted since Paul Graham is not ordinary folk writing clickbaity titles here. He indirectly founded the website you're commenting on so your comment might have been received as bashing on him.
This is most likely why GP was downvoted:
> - Me: [Doesn't click and] thinks "Would ya look at that? An article/author which is contrarian probably just to be contratian. I'm gonna find something else to read..."
Low-value post that seems to be deliberately avoiding real contribution and participation in the conversation while simultaneously admitting that they didn't read and (almost certainly) won't read the article. There's no point to these kinds of comments, and they should be downvoted.
He is "ordinary folk writing clickbaity titles". People here just pay too much attention.
So PHD in computer science, wrote programming books still recommended by very smart people 30 years after the fact, launched, ran and sold successful startup, and now successful VC is... ordinary? People like Peter Norvig say "On Lisp" is one of the best books on lisp! I'm in the software acquisition business, so I talk to founders getting ready to exit every month. That set of combined successes is most emphatically not ordinary.
I find it very strange that people are voting this down. I mean seriously, we're talking about whether someone writing about development is "ordinary"... Given the above credentials, you're seriously arguing that PG is in the same category as ordinary random dev writing programming articles? Seriously? He's just not. That's just wrong. He's got stellar academic and business credentials - that combination is not common. I guess haters gonna hate and all that.
https://worldwarwings.com/wp-content/uploads/2019/05/survivo...
Keep talking about business "success" stories and their secrets.
He isn't in the same category as an average programmer. He's way lower, since he doesn't work in the field any more.
He is something of an expert on business, I suppose, if you take having lots of money as evidence of smarts rather than as evidence of bad character.
Vastly overestimating the average programmer.
But not the average programmer's estimation of their own ability! ;-)
