Do Things That Don't Scale (2013)
88 comments
·August 15, 2025xwowsersx
epolanski
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.
pimlottc
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.
minnapps
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.
cjs_ac
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.
jlundberg
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 :)
shin_lao
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...
nine_k
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.
datadrivenangel
Pets.com died because they scaled too fast and couldn't handle the load and didn't have the cashflow to fill orders.
It's a valid concern, but most people radically overestimate the likeliness.
robocat
When anything fails (even a business) a suitable excuse is found (maybe a story that executives can sell to investors). If you were there then sometimes you know what the actual hidden reason was (often an intersection of multiple causes).
It's a human pattern for businesses to discover a strawman, build a story about that strawman, then share that story widely.
Not saying the above answer about pets.com is wrong - just that in my experience you need to be cynical enough to ignore the story and then resourceful enough to find a better causal reason.
Edit:
Scaling is NOT given as a reason. "Despite only earning $619,000 in revenue, the business spent more than $70 million on advertising and marketing", "the company sold its pet products under their original purchase price", "bulk items like dog food were expensive to ship".
I guess another reason is that people make up stories like blaming scaling?
I'll make one up: Amazon owned 50% of pets.com and Amazon encouraged it to fail.
nine_k
"Didn't have the cashflow" sounds more like lack of investment / loans, but I agree, explosive growth that catches you unready can happen. It seems to be an exception rather than the rule though. But everyone strives to be an exception, I know :)
al_borland
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.
skydhash
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.
nonethewiser
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.
chairmansteve
Or boiled down to "don't solve problems you don't have".
sneak
> "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.
paulddraper
A lot of people have not built a successful company either.
begueradj
> "don't try to behave like companies much bigger than you"
That's a good point.
qualeed
>Seeing a lot of people shit on Paul
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.
tombert
I don't think pg is wrong on this at all, and I don't run a business so this is largely me just bloviating, but a large part of the fun of a project for me is figuring out how it's going to scale.
Obviously there's software scaling, which of course on this forum doesn't need much explanation; making code maintainable and making it work with lots of users is just something I find really interesting and fun.
But it's not just software; there's also other projects that I work on that to me the fun part is figuring out "if I had to do this a million times how could I make this easier?"
Stuff like figuring out ways of batch-cooking food so that I could handle dozens of people, for example, is something I find pretty enjoyable, even if I will never have a situation where I need to feed dozens of people. Figuring out how to get mass production of 3D printed parts using OctoFarm is fun even if I never really need more than one part at a time. Buying industrial-sized CO2 containers and kegs for my soda habit makes me feel cool.
I dunno, I guess to me it sort of sucks the fun out of things to have to do things in the non-scalable way, but I guess that's sort of pg's point.
dang
Related. Others?
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)
NaOH
Show HN: A directory of startups that did things that don't scale - https://news.ycombinator.com/item?id=41490865 - Sept 2024 (12 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)
wdaher
Scalability is overrated - https://news.ycombinator.com/item?id=34656776 - Feb 2023 (232 comments)
paulpauper
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.
anonyonoor
This was the very first post I saw on Hacker News.
Glad to see it reposted every now and then. Makes me nostalgic.
nicodjimenez
The most important piece ever written about startups, probably. Applicable to doing anything new.
For startups, the devil's in the details though. The goal is to scale but you get there by doing things that don't scale successively.
null
monkeyelite
I don’t know how people are thinking this is about scaling web application capacity unless you are responding to the title.
sdotdev
I really agree with this.
I used to live with the mindset and if I didn't elevate far in a week I would just give up.
Things really take time.
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.