Something I heard recently on some podcast which really resonated was (paraphrasing): "Inertia is the biggest issue for a startup. The world doesn't like you, doesn't think it needs you... and you've got to invert that. You have to create momentum by scratch and the most important thing a founder does, by an order of magnitude, is invert inertia. Literally, in a physical sense. Like the world stays at rest and you've got to create momentum." With that in mind, it makes sense to do things that don't scale... because in the beginning, you're not trying to optimize a machine that's already running. You're trying to get the engine to turn over at all. PG's point is that scalable growth comes later; first, you have to manually crank the thing into motion. You do manual stuff not because it's efficient, but because it's the only way to get traction when no one's looking for you in the first place. And that's how you learn what actually works, how you build momentum one user at a time, and how you prove there's something worth scaling at all.
I also think that the biggest value in doing things manually is that you actually learn.
One of my clients used to make a nice curated list of the important financial and stock market news of the week, it was a niche part of a niche product but people loved it.
At some point he thought about automating everything, it became less curated, more spammy, it lost any value and in the end so did the product. Sure there was more news, but it was less curated, edited and the signal to noise ratio got worse.
In fact what they did manually was more valuable even if the scope was smaller.
Many companies don't understand that and rush into premature optimization.
I'll have another example: one of my clients wanted a scraper to automate something his company needed to do manually: check competitors prices on their ecommerces.
I built it, way simpler than they wanted (they thought they wanted an app with a proper front end, turns out it was better for both to produce an excel spreadsheet with the data) and they were happy.
Then after some time they understood that they were missing part of the experience: navigating their competitors manually allowed them to see new approaches to show the catalogue, new trends and products, they were actually learning from the competition.
Eventually they realized and got back to doing it, and left my scraper just for price analysis.
But the overwhelming majority of my clients keep putting automation before the product and problem and misses important learning opportunities.
People focus on the primary function they want to automate and forget about all the ancillary functions and effects, which, in aggregate, can be as important as the core function.
That's a really good point, doing things manually is an important part of being connected to a job and its outcomes. I will also say, sometimes you need a few hours of little manual tasks to break up the day between brain-heavy tasks.
Similar thing happens in sales. A gen-AI driven sales tool might write perfect copy and reach 1000 people. But when you go by each person and write a hand-written email to them, the ancillary thing is that you learn about that person. You develop intuition about what sort of people would be right people and develop a perspective about why you can solve their problem or not. This completely gets lost when you automate and play numbers game. This is especially important in zero to one phase.
“Inverting inertia” is a great framing, but it mostly applies to one type of startup. Sequoia’s Arc framework shows there are three paths: Hair on Fire (urgent pain, momentum matters), Hard Fact (people live with the pain, you have to change habits), and Future Vision (people don’t even believe it’s possible, you need to build credibility). Doing unscalable things is vital in Hair on Fire, but in the other two paths the playbook is more about reframing reality or creating belief before momentum even starts.
My theory is that there are three regimes: Not Scaling, Scaling, and Antiscaling.
Not Scaling is about crossing and shoring up your moat. Scaling is when your app has enough hype around it that your customers recruit new customers, and all you have to do is add new machines or shard the database or whatever to handle increased demand.
Antiscaling is when you turn into the thing that everyone hates about the modern web. Antiscaling is when intelligence agencies want to talk to you about how your chat app is used by terrorists, when cities want to licence access to your ridesharing or takeaway delivery app, when pieces of legislation are passed that are specifically designed to target your company, when you're sufficiently well-known as the founder of an app that people are making memes about you and tracking your personal movements.
You don't have to take over the world, you just have to make money. People who try to change the world often change it for the worse; just try to make something useful, and maybe the world will like it.
How about extreme and utter irrelevance (such as after building a thing nobody wants)?
Or how about this, arguably the most common: slightly successful; nobody hates it but nobody loves it either. Something people feel mildly positive about, but there is zero “hype” and also no “moat” and nobody cares enough to hate it.
A recommended read for all early stage founders and for employees too if you are one of the earlier team members.
One thing we do and still do even at 15+ people is we call each and every new signup on the phone.
We do it for these reasons:
1) How did you find us?
2) Do you need help starting?
3) (Implicit: we care)
It probably works because what we have it’s a B2B platform.
However, our target group is software developers and maybe surprisngly these phone calls are really really nice.. once you get over the ”no, I am noy calling you to sell anything”-phase :)
But the point he makes is completely valid that you have to start by doing things yourself and not automating. I think the biggest value of that is you actually build a more granular mental model of how things work that simply can't be captured by slides and memos.
You also build what the cool kids now call taste. It's what does good look like and why? And often it means having a strong perspective on decisions people would be either ambivalent to or not even recognize that a decision is needed.
AI means many will skip and try to automate prematurely.
At www.socratify.com We build our pedagogical content manually. Even though everyone tells us that we should use AI, we want to curate a set of context that's high quality because it's what our users interact with
I'm sure we'll semi-automate on the validation side pretty quickly, but it's hard to replace raw human brainpower even with the smartest models and we learn a lot quickly.
Seeing a lot of people shit on Paul, which I guess, why not, but it's not super useful or positive.
I think this is a fairly good essay which can be boiled down to "don't do premature optimization" or "don't try to behave like companies much bigger than you".
There are three advantages to this:
1/As a founder, get your hands dirty, even if in the grand scheme of things it's inefficient. You'll get first hand experience and feedback.
2/Avoid the upfront cost of "something that scales", and thus get quicker feedback.
3/Makes you different, very important in the beginning.
"Do things that don't scale" is a way to drive the point home and must not be taken literally...
Many people are concerned with becoming an overnight success and being unable to withstand the load, and losing the momentum. So they build highly scalable things before the slightest need for horizontal scaling even arises.
I think that vertical scaling is underappreciated. Just throwing more resources at your monolithic backend can buy you quite enough time to understand how to best scale your product. More importantly, it may give you the time to reconsider what are the key strengths of your product that the users are for, and thus to understand what needs scaling.
Also, when users really love your product, they will excuse you for its spotty performance. Early Twitter was built on a hugely inadequate architecture (a Rails app), and kept melting and crashing; remember the "fail whale"? Despite that, users were coming to it in droves, because it did the key things right.
To my mind, the early stage is all about easy iteration and finding out what makes users happy and enthusiastic. Ignore scaling; experiment, listen to the users, talk to the users. When it clicks, you can consider scaling. It may happen at a point you did not anticipate, and could not optimize for.
Technology is a tool, an instrument. It's great to have a Stradivarius, but you need some good music first.
It’s also important to realize that not every successful or worthwhile business has millions or billions of users that requires extreme optimization and scalability.
I work on internal tools at my company. We know how big our environment is, there isn’t much sensitivity to performance, and we don’t see random spikes that we don’t cause ourselves. Yet I had someone on my team who was obsessed with optimizing everything, to the point of changing his entire code base to a new language that only he knew, so he could save a few milliseconds on paper. Aside from him, no one noticed, no one cared. His optimizations just introduced risk, as he was the only one who could support what he built. When he left, we threw the whole thing away at management’s demand. Had it been a little more simple and slow, someone else probably could have taken it over without as much effort.
My own ethics is mostly about collaboration and confidence. I make sure that I’m ready to offload work whenever I want, and knowing what I ship is working. Other thing are just fun experiments. If it does not impact positively the business/consumers, I’m very happy to not do it. God knows that there’s always something to work on that does.
> "don't try to behave like companies much bigger than you"
This is such good advice for organizations at all stages. As a consultant I spend a lot of time talking startups and small companies out of hobbling themselves by adopting policies they think they have to simply because they're a corporation, when those policies only make sense when you have at a minimum hundreds of people involved in the org.
Everything from k8s to nosql to overly restrictive security policies. The Netflix employee handbook/guide really drove this point home to me. When you're small, and you're hiring well, you can afford to actually delegate real responsibility to your staff and let them use their judgement. Not everything needs to be a hard and fast rule until and unless there's an unacceptable level of risk or a demonstrated problem at hand.
This relates to dealing with people too. A few times I've hired people who seemed to have good interpersonal skills, for people-facing roles. But for some reason, as soon as they were sending an email on behalf of the company, ie. to a customer or supplier, suddenly they're communicating like a soulless corporate automaton. Like, you don't have to pretend to be a cog in a massive corporation; no one actually likes receiving that kind of communication! Perhaps at a certain scale, when you're employing thousands of customer service agents, you'll need them to follow a strict script to maintain quality control. (Or maybe not.) But it's certainly not necessary at a company with single or double digit employees.
There is a key difference from "don't do premature optimization." "Premature optimization" suggests the scaled version is optimal. It might not be worth the resource cost to achieve it, but disregarding that, its the best.
Whereas "Do things that Dont Scale" is suggesting the non-scaled process may be the optimal one. For example (and this sort of thing is in the article IIRC), giving direct contact details to the CEO instead of a generic form that get's sent to some shared customer service/sales inbox. Way better process for selling your product. The inquiry form scales but its in no way a premature "optimization."
Another way of putting it is that SCALING IS BAD. Or to be a bit more nuanced, it's a necessary evil. It's complex. It's resource intensive. It creates distance between you and your customer. Of course business goals and environment may dictate it, but that doesn't mean none of the processes are degrading in quality. So its more like dont do "premature process degradation" than "premature optimization" I think.
Hardly "a lot". There's like three negative comments and one of them is strictly criticizing the article itself and not paul. I thought it brought up some good points.
Stripe is one of the most successful startups we've funded, and the problem they solved was an urgent one. If anyone could have sat back and waited for users, it was Stripe. But in fact they're famous within YC for aggressive early user acquisition.
This was 12 years ago. Even he couldn't have imagined how successful it would still become. I wish there were I way I could have invested in it.
Readit News
One of my clients used to make a nice curated list of the important financial and stock market news of the week, it was a niche part of a niche product but people loved it.
At some point he thought about automating everything, it became less curated, more spammy, it lost any value and in the end so did the product. Sure there was more news, but it was less curated, edited and the signal to noise ratio got worse.
In fact what they did manually was more valuable even if the scope was smaller.
Many companies don't understand that and rush into premature optimization.
I'll have another example: one of my clients wanted a scraper to automate something his company needed to do manually: check competitors prices on their ecommerces.
I built it, way simpler than they wanted (they thought they wanted an app with a proper front end, turns out it was better for both to produce an excel spreadsheet with the data) and they were happy.
Then after some time they understood that they were missing part of the experience: navigating their competitors manually allowed them to see new approaches to show the catalogue, new trends and products, they were actually learning from the competition.
Eventually they realized and got back to doing it, and left my scraper just for price analysis.
But the overwhelming majority of my clients keep putting automation before the product and problem and misses important learning opportunities.
Deleted Comment
Not Scaling is about crossing and shoring up your moat. Scaling is when your app has enough hype around it that your customers recruit new customers, and all you have to do is add new machines or shard the database or whatever to handle increased demand.
Antiscaling is when you turn into the thing that everyone hates about the modern web. Antiscaling is when intelligence agencies want to talk to you about how your chat app is used by terrorists, when cities want to licence access to your ridesharing or takeaway delivery app, when pieces of legislation are passed that are specifically designed to target your company, when you're sufficiently well-known as the founder of an app that people are making memes about you and tracking your personal movements.
You don't have to take over the world, you just have to make money. People who try to change the world often change it for the worse; just try to make something useful, and maybe the world will like it.
When a measure (e.g. profit) becomes a target, it ceases to be a good measure.
-- Goodhart's Law.
The typical example is something like headcount targets that lead to employing or laying off some of the wrong people.
I think that profit is more of a force like gravity than a future target that distorts strategy.
Deleted Comment
Dead Comment
How about extreme and utter irrelevance (such as after building a thing nobody wants)?
Or how about this, arguably the most common: slightly successful; nobody hates it but nobody loves it either. Something people feel mildly positive about, but there is zero “hype” and also no “moat” and nobody cares enough to hate it.
Ask HN: PG's 'Do Things That Don't Scale' manual examples? - https://news.ycombinator.com/item?id=38010992 - Oct 2023 (316 comments)
Do Things that Don't Scale (2013) - https://news.ycombinator.com/item?id=26086196 - Feb 2021 (31 comments)
PG: “Do Things that Don't Scale” – What are some examples? - https://news.ycombinator.com/item?id=25898671 - Jan 2021 (2 comments)
Ask HN: How did you 'do things that don't scale' for your B2B startup? - https://news.ycombinator.com/item?id=15290433 - Sept 2017 (9 comments)
Do Things That Don’t Scale (2013) - https://news.ycombinator.com/item?id=14957007 - Aug 2017 (37 comments)
Do Things that Don't Scale - https://news.ycombinator.com/item?id=6041765 - July 2013 (207 comments)
Ask HN: What are some hacks of real founders who did things that don't scale? - https://news.ycombinator.com/item?id=18400020 - Nov 2018 (267 comments)
Why we're doing things that don't scale - https://news.ycombinator.com/item?id=6102285 - July 2013 (34 comments)
One thing we do and still do even at 15+ people is we call each and every new signup on the phone.
We do it for these reasons:
1) How did you find us?
2) Do you need help starting?
3) (Implicit: we care)
It probably works because what we have it’s a B2B platform.
However, our target group is software developers and maybe surprisngly these phone calls are really really nice.. once you get over the ”no, I am noy calling you to sell anything”-phase :)
But the point he makes is completely valid that you have to start by doing things yourself and not automating. I think the biggest value of that is you actually build a more granular mental model of how things work that simply can't be captured by slides and memos.
You also build what the cool kids now call taste. It's what does good look like and why? And often it means having a strong perspective on decisions people would be either ambivalent to or not even recognize that a decision is needed.
AI means many will skip and try to automate prematurely.
At www.socratify.com We build our pedagogical content manually. Even though everyone tells us that we should use AI, we want to curate a set of context that's high quality because it's what our users interact with
I'm sure we'll semi-automate on the validation side pretty quickly, but it's hard to replace raw human brainpower even with the smartest models and we learn a lot quickly.
I think this is a fairly good essay which can be boiled down to "don't do premature optimization" or "don't try to behave like companies much bigger than you".
There are three advantages to this:
1/As a founder, get your hands dirty, even if in the grand scheme of things it's inefficient. You'll get first hand experience and feedback. 2/Avoid the upfront cost of "something that scales", and thus get quicker feedback. 3/Makes you different, very important in the beginning.
"Do things that don't scale" is a way to drive the point home and must not be taken literally...
I think that vertical scaling is underappreciated. Just throwing more resources at your monolithic backend can buy you quite enough time to understand how to best scale your product. More importantly, it may give you the time to reconsider what are the key strengths of your product that the users are for, and thus to understand what needs scaling.
Also, when users really love your product, they will excuse you for its spotty performance. Early Twitter was built on a hugely inadequate architecture (a Rails app), and kept melting and crashing; remember the "fail whale"? Despite that, users were coming to it in droves, because it did the key things right.
To my mind, the early stage is all about easy iteration and finding out what makes users happy and enthusiastic. Ignore scaling; experiment, listen to the users, talk to the users. When it clicks, you can consider scaling. It may happen at a point you did not anticipate, and could not optimize for.
Technology is a tool, an instrument. It's great to have a Stradivarius, but you need some good music first.
It's a valid concern, but most people radically overestimate the likeliness.
I work on internal tools at my company. We know how big our environment is, there isn’t much sensitivity to performance, and we don’t see random spikes that we don’t cause ourselves. Yet I had someone on my team who was obsessed with optimizing everything, to the point of changing his entire code base to a new language that only he knew, so he could save a few milliseconds on paper. Aside from him, no one noticed, no one cared. His optimizations just introduced risk, as he was the only one who could support what he built. When he left, we threw the whole thing away at management’s demand. Had it been a little more simple and slow, someone else probably could have taken it over without as much effort.
This is such good advice for organizations at all stages. As a consultant I spend a lot of time talking startups and small companies out of hobbling themselves by adopting policies they think they have to simply because they're a corporation, when those policies only make sense when you have at a minimum hundreds of people involved in the org.
Everything from k8s to nosql to overly restrictive security policies. The Netflix employee handbook/guide really drove this point home to me. When you're small, and you're hiring well, you can afford to actually delegate real responsibility to your staff and let them use their judgement. Not everything needs to be a hard and fast rule until and unless there's an unacceptable level of risk or a demonstrated problem at hand.
Whereas "Do things that Dont Scale" is suggesting the non-scaled process may be the optimal one. For example (and this sort of thing is in the article IIRC), giving direct contact details to the CEO instead of a generic form that get's sent to some shared customer service/sales inbox. Way better process for selling your product. The inquiry form scales but its in no way a premature "optimization."
Another way of putting it is that SCALING IS BAD. Or to be a bit more nuanced, it's a necessary evil. It's complex. It's resource intensive. It creates distance between you and your customer. Of course business goals and environment may dictate it, but that doesn't mean none of the processes are degrading in quality. So its more like dont do "premature process degradation" than "premature optimization" I think.
That's a good point.
Hardly "a lot". There's like three negative comments and one of them is strictly criticizing the article itself and not paul. I thought it brought up some good points.
This was 12 years ago. Even he couldn't have imagined how successful it would still become. I wish there were I way I could have invested in it.
Glad to see it reposted every now and then. Makes me nostalgic.