Do Things That Don't Scale (2013)(paulgraham.com)
paulgraham.com
Do Things That Don't Scale (2013)
https://paulgraham.com/ds.html
131 comments
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.
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.
This fuels my feelings on why most uses of GenAI are such a step back for society's non-short-term effectiveness.
[deleted]
That's why "make something people want" is such a core saying for startups.
“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.
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.
> you just have to make money.
When a measure (e.g. profit) becomes a target, it ceases to be a good measure.
-- Goodhart's Law.
When a measure (e.g. profit) becomes a target, it ceases to be a good measure.
-- Goodhart's Law.
I have not seen profit used as a misplaced target in Goodhart’s Law before.
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.
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.
An argument could be made for the wrong “time horizon” of profit. Target quarterly profits and you might cannibalize your business. Target profits to far in the future and you might go bankrupt.
But in the general case I mostly agree with you. Sometimes though, businesses reach a market saturation level where “making the line go up” every quarter is bad for the health of the business.
But in the general case I mostly agree with you. Sometimes though, businesses reach a market saturation level where “making the line go up” every quarter is bad for the health of the business.
It may not be the usual example, but I believe it an apt one: shrinkflation and other kinds of forever "cutting costs" to the detriment of everything else is so normalised it's a cliche. We expect planned obsolescence now.
Infinite monetary inflation ensures this. It's literally baked into current global monetary policy.
in this case it is apt though because the actual goal is not turning "into the thing that everyone hates about the modern web." according to the antiscaling category but the metric given for avoiding that is making money.
profit is usually not the misplaced metric, because profit is the goal.
But if you have another goal such as well-being of the people of your country then you might set up GDP measures and call it a success when everyone is miserable. (I know GDP does not directly measure profit, this is in the nature of a real world example how something usually not thought of as a Goodhart's law measure might actually work)
profit is usually not the misplaced metric, because profit is the goal.
But if you have another goal such as well-being of the people of your country then you might set up GDP measures and call it a success when everyone is miserable. (I know GDP does not directly measure profit, this is in the nature of a real world example how something usually not thought of as a Goodhart's law measure might actually work)
Its a not a target for your company, its a target for capitalism in general.
Every economic systems aims to benefits society in general, and capitalism claims that (to great extent) free market allocation of capital is the best way to do that, using profit (or net increase in capital) as the optimizing function.
Well, when that measure becomes the target, it can get hacked, where profit can be maximised without getting closer to the intended goal. So you can make a very profitable company that just makes society worse. And alot of times that happens when these companies see regulations designed to limit their damage to society as just restrictions on their profitability, rather than understanding that the real goal of their company is to make society better, and profit is just the carrot hanging in front of their individual hamster wheel.
Every economic systems aims to benefits society in general, and capitalism claims that (to great extent) free market allocation of capital is the best way to do that, using profit (or net increase in capital) as the optimizing function.
Well, when that measure becomes the target, it can get hacked, where profit can be maximised without getting closer to the intended goal. So you can make a very profitable company that just makes society worse. And alot of times that happens when these companies see regulations designed to limit their damage to society as just restrictions on their profitability, rather than understanding that the real goal of their company is to make society better, and profit is just the carrot hanging in front of their individual hamster wheel.
[deleted]
I feel this is an insanely distorted take.
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.
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.
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)
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)
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)
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)
Scalability is overrated - https://news.ycombinator.com/item?id=34656776 - Feb 2023 (232 comments)
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 :)
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 :)
Of course there's survivor bias.
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.
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...
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.
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.
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.
It's a valid concern, but most people radically overestimate the likeliness.
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.
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.
"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 :)
You hire your sales team for their infectious enthusiasm. Then they get some momentum going and you don't want to try to stop that momentum, but now they're bringing you so much fame that it's now tipping into infamy.
And every time you ask them to slow down, they tell you a very convincing story about why if anything we should be going faster.
I worked for a small consulting shop where the founder was one of these people. I had to try three times over about 2 years to quit. The last time I just kept talking over him like a priest doing an exorcism and shoving my 2 weeks' at him.
And every time you ask them to slow down, they tell you a very convincing story about why if anything we should be going faster.
I worked for a small consulting shop where the founder was one of these people. I had to try three times over about 2 years to quit. The last time I just kept talking over him like a priest doing an exorcism and shoving my 2 weeks' at him.
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.
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 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.
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.
Or boiled down to "don't solve problems you don't have".
> "don't try to behave like companies much bigger than you"
That's a good point.
That's a good point.
A lot of people have not built a successful company either.
>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.
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.
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.
This was the very first post I saw on Hacker News.
Glad to see it reposted every now and then. Makes me nostalgic.
Glad to see it reposted every now and then. Makes me nostalgic.
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.
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.
YC genuinely changed the game by making seed funding more accessible. Paul Graham, Jessica Livingston, and the entire YC team saw how broken the system was and fixed it.
It was ridiculously hard to raise seed before YC. I remember pitching a group of 8 angry partners straight out of a cigar filled banker like black and white movie around 2013.
Credit where it’s due. They fixed a broken market.
It was ridiculously hard to raise seed before YC. I remember pitching a group of 8 angry partners straight out of a cigar filled banker like black and white movie around 2013.
Credit where it’s due. They fixed a broken market.
That's arguable. More accessible for whom? It was - before YC - and it still is hard to raise seed. Not much changed in this system. Only that a player like YC got too big - and has weakened the position of bootstrapped founders. They also get to say on which ideas founders should work on - and the founders are closely listening instead of building things they really believe in and care about.
I wish people running OpenAI and similar companies read Do Things That Don’t Scale and took it seriously. With the amount of money at their disposal, they could honestly license their training data and not engage in piracy. Unfortunately, they preferred to do things that do scale (scrape & steal), in the hopes that if they do as much as possible as sneakily and quickly as possible they’ll get away with it, and the question about paying people who are unwitting ghost content producers for their commercial software would never come up until it’s too late.
This has nothing to do with scaling and everything to do with not spending money you don't need to (one half of the ultimate goal in capitalism).
Sure—just as polluting the environment and our bodies with toxic waste has to do with not spending money they don’t need to spend.
Fully free market cannot sustainably exist in presence of bad faith actors. Capitalism does not imply that every company must be a bad faith actor, but many companies, including in this context particularly OpenAI, Microsoft et al., are such actors. This scenario is exactly where the regulation is supposed to come in.
Fully free market cannot sustainably exist in presence of bad faith actors. Capitalism does not imply that every company must be a bad faith actor, but many companies, including in this context particularly OpenAI, Microsoft et al., are such actors. This scenario is exactly where the regulation is supposed to come in.
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.
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.
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.
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.
I volunteered at a food for homeless place and batch cooked. It was fun. Also I weirdly enjoy cooking a kilo of rice more than 100g, knowing future me can just grab some rice later in the week no hassles.
Yeah, it’s also easier to get the portions right with a bigger batch for food; tripling the portion size triples the margin of error.
[deleted]
It is entirely possible to do these manual things, acquiring users one or two at a time, and never having achieved escape velocity where your product does not garner enough attention such that its users recommend the product to others, and it grows by word of mouth itself.
I've built at least two of these that became the most popular solution in their space for a given problem, and if you don't have the constraints of a VC investor wanting their returns and eventually shutting you down, then you can realistically go for years without significant enough growth to even get past par with your direct competitors.
Or you realize that your competitors were never even big enough to meaningfully compete with in the first place because you didn't aim high enough.
I've built at least two of these that became the most popular solution in their space for a given problem, and if you don't have the constraints of a VC investor wanting their returns and eventually shutting you down, then you can realistically go for years without significant enough growth to even get past par with your direct competitors.
Or you realize that your competitors were never even big enough to meaningfully compete with in the first place because you didn't aim high enough.
This is a great article! My cofounders and I read it when we were first starting our business, and it significantly impacted the decisions we make, usually for the better. But don’t forget to scale at some point!! For example, we’re still doing our own bookkeeping and tax filing. When we started it was simple and it was a “thing that doesn’t scale” which we could still do. But at this point it’s a waste of time. We’re finally outsourcing it, probably a year later than we should have. I think we overindexed on Paul’s advice a bit. Which, to be clear, is still really really good advice, just don’t take it too far.
Edit: business is mydragonskin.com
Edit: business is mydragonskin.com
> your initial model of users is always inaccurate, even if you're one of them
Love this. It's one of the counterintuitive (-seeming) things about building for a fellow engineer, too, and applies to internal tools you inevitably build.
Love this. It's one of the counterintuitive (-seeming) things about building for a fellow engineer, too, and applies to internal tools you inevitably build.
After reading this, it's clear that:
1) It's more important to hit the target (what users need) than to throw quickly or with force.
2) We often don't realize how scalable things are.
I wonder if Paul has a take about the same in this era of AI
>Scale things that don’t do
I rarely do comments just to say thank you for the great laugh, but when I do, I do it on HN.
This is the best comment I’ve ever seen
It is pretty profound. AI / deep learning failed to solve self-driving, but they’re good at moving text and code around, which humans still have to check
It’s arguable whether that’s “doing”
I’d say it’s more spreading knowledge around, which is super valuable, but not what is being advertised
The problem with self driving is that bad decisions can kill you, before anyone can check if it was a bad decision
It’s arguable whether that’s “doing”
I’d say it’s more spreading knowledge around, which is super valuable, but not what is being advertised
The problem with self driving is that bad decisions can kill you, before anyone can check if it was a bad decision
> I’d say it’s more spreading knowledge around
How is it spreading knowledge around? A lot of times it gives half backed answers and a lot of beginners are using it while learning. That's not a good mix in my opinion.
I've been helping someone who's learning programming and I've had a look at their code. All of it is vibe coded. And the vibes are nightmarish, I don't think the AI is helping at all.
The only thing it's useful for is sparing expert programmers some tedious work, that's my perception as a programmer.
How is it spreading knowledge around? A lot of times it gives half backed answers and a lot of beginners are using it while learning. That's not a good mix in my opinion.
I've been helping someone who's learning programming and I've had a look at their code. All of it is vibe coded. And the vibes are nightmarish, I don't think the AI is helping at all.
The only thing it's useful for is sparing expert programmers some tedious work, that's my perception as a programmer.
Well, if you tell me that many people are using LLMs poorly, and in a way that won't benefit them or their team in the long term, then I wouldn't be too surprised.
There are probably more ways to use them poorly than ways to use them well.
And AI companies are pushing usage patterns that may make you dependent on them.
---
But I mention 4 ways that LLMs helped me recently here
https://lobste.rs/s/zxppfh/all_cool_kids_are_doing_it#c_xfnz...
i.e. VimScript, SQL, login shells, Linux container syscalls -- with some results you can see
I mention that "give me your best argument against X" is a good prompt -- they can do that
And I also don't use them to edit code for me (right now) -- I type the code myself, TEST it, and internalize it
So for those cases, and many others, they are "spreading knowledge" to me, simply because I can directly query them without reading the manual (or suffering through slow web pages with ads on them)
The end game might be ads, which is depressing. But actually it's remarkable that you can run high quality models locally, whereas you could have NEVER run Google locally. I use LLMs as a better Google, as a sophisticated text calculator. But they are significantly more than that too
I have definitely run into cases where LLMs slow me down, but I now avoid those usage patterns
There are probably more ways to use them poorly than ways to use them well.
And AI companies are pushing usage patterns that may make you dependent on them.
---
But I mention 4 ways that LLMs helped me recently here
https://lobste.rs/s/zxppfh/all_cool_kids_are_doing_it#c_xfnz...
i.e. VimScript, SQL, login shells, Linux container syscalls -- with some results you can see
I mention that "give me your best argument against X" is a good prompt -- they can do that
And I also don't use them to edit code for me (right now) -- I type the code myself, TEST it, and internalize it
So for those cases, and many others, they are "spreading knowledge" to me, simply because I can directly query them without reading the manual (or suffering through slow web pages with ads on them)
The end game might be ads, which is depressing. But actually it's remarkable that you can run high quality models locally, whereas you could have NEVER run Google locally. I use LLMs as a better Google, as a sophisticated text calculator. But they are significantly more than that too
I have definitely run into cases where LLMs slow me down, but I now avoid those usage patterns
Yeah, the other day a front end dev created a branch in some elixir code. They added a pile of tests, and asked a (new hire) back end dev to finish off the work. The tests were 100% vibe coded. I knew the code well, and after looking realized that the tests could never ever pass. The tests were rubbish.
Crap part was, the new BE dev was totally lost for a long time trying to figure out how to make them pass. Vibe killed his afternoon.
Things that don't scale do.
You might be missing the joke: the words are not just shuffled into a random order, but form a new valid sentence that is on point. While your sentence is also grammatically valid and perhaps even true if interpreted in a particular way, it has little relevance to the context.
>You might be missing the joke:
really? :)
speaking of jokes, it may be you who is the joker.
to paraphrase that joke about consultants ("a consultant is a person who knows more and more about less and less, until eventually he knows everything about nothing"):
you may be the kind of person who knows the theory of everything, but the practice of nothing.
and you might be missing the rather obvious fact that I don't give a fuck about whether I miss the joke or not. I was just putting out my own comment. you see, I may be one of the few people here, who happen to have that seemingly somewhat vanishing ability of being able to think for myself, and not just echo the opinion of the hive mind, and not kowtow to arbitrary user-wannabe-moderator defined conventions, whether of hn or other places, like you seem to be doing, in your comment above. I don't have to care whether it has relevance to the context or not, particularly not when some random person like you thinks so.
and ...
as is often said on hn, the plural of anecdote is not data. that is what your comment is, just an anecdote - to me, anyway.
so do not stupidly try to impose your way of thinking upon me, which is exactly what you tried to do in your comment above.
and ...
"different strokes for different folks" - sound familiar?
and because of all the above, and much more, which everyone sensible person knows, as amy hoy has famously said - fuck hn. fuck some of the people on it anyway, because they need it, because of that asshole behavior.
qed.
which is latin for - what had to be demonstrated.
really? :)
speaking of jokes, it may be you who is the joker.
to paraphrase that joke about consultants ("a consultant is a person who knows more and more about less and less, until eventually he knows everything about nothing"):
you may be the kind of person who knows the theory of everything, but the practice of nothing.
and you might be missing the rather obvious fact that I don't give a fuck about whether I miss the joke or not. I was just putting out my own comment. you see, I may be one of the few people here, who happen to have that seemingly somewhat vanishing ability of being able to think for myself, and not just echo the opinion of the hive mind, and not kowtow to arbitrary user-wannabe-moderator defined conventions, whether of hn or other places, like you seem to be doing, in your comment above. I don't have to care whether it has relevance to the context or not, particularly not when some random person like you thinks so.
and ...
as is often said on hn, the plural of anecdote is not data. that is what your comment is, just an anecdote - to me, anyway.
so do not stupidly try to impose your way of thinking upon me, which is exactly what you tried to do in your comment above.
and ...
"different strokes for different folks" - sound familiar?
and because of all the above, and much more, which everyone sensible person knows, as amy hoy has famously said - fuck hn. fuck some of the people on it anyway, because they need it, because of that asshole behavior.
qed.
which is latin for - what had to be demonstrated.
also, i despise people who use weasel words.
you used some in your comment:
>You might be
>perhaps even true
>if interpreted in a particular way
>little relevance
creepy af.
you used some in your comment:
>You might be
>perhaps even true
>if interpreted in a particular way
>little relevance
creepy af.
I am afraid he does and it's not good...
https://news.ycombinator.com/item?id=44913240
for him...
https://news.ycombinator.com/item?id=44913240
for him...
A HN comment linking to an HN post of a Reddit post of a screenshot of a tweet.
https://xkcd.com/1683/
https://xkcd.com/1683/
Relevant discussion thread https://news.ycombinator.com/item?id=38010992
I loved your "do things that don't scare" story from the other thread!
https://news.ycombinator.com/item?id=38019292
https://news.ycombinator.com/item?id=38019292
thank you!
I think everything you do has to be something that CAN be scaled.
I mean if your company makes boats that can ONLY be made by 1 person and that's you - then even if "making boats" is something that CAN scale - your company specifically can't. Which means you'll only ever have customers that are hard to get, and each time you finish you can eat and pay rent again for a week or two - then start over at finding a customer (unless you have a waiting list, but that's magical thinking)
The nice thing however, is that making boats CAN SCALE. Because you can teach someone else how to make the sails, etc... So while PG is trying to write an edgy headline, he doesn't mean it - he would never advocate for you to always make the boat yourself for the rest of time.
I mean if your company makes boats that can ONLY be made by 1 person and that's you - then even if "making boats" is something that CAN scale - your company specifically can't. Which means you'll only ever have customers that are hard to get, and each time you finish you can eat and pay rent again for a week or two - then start over at finding a customer (unless you have a waiting list, but that's magical thinking)
The nice thing however, is that making boats CAN SCALE. Because you can teach someone else how to make the sails, etc... So while PG is trying to write an edgy headline, he doesn't mean it - he would never advocate for you to always make the boat yourself for the rest of time.
I don’t know how people are thinking this is about scaling web application capacity unless you are responding to the title.
Even so its true there too. Just use postgres with monolith, monorepo on a single VM (yes!) until you need more. Do have DR of course and security posture from day 1.
Feel the pain badly that microservices or aurora or k8s solve before using them!
Also pets not cattle. A $100/m hetzner dedi with a CDN on top is probably a tardis for most startups and can scale you up to a lot of traffic. With a setup like that yes you can install the Web server and the database on the same damn machine, and find it ridiculously overprovisioned while costing less than your incorporation.
Feel the pain badly that microservices or aurora or k8s solve before using them!
Also pets not cattle. A $100/m hetzner dedi with a CDN on top is probably a tardis for most startups and can scale you up to a lot of traffic. With a setup like that yes you can install the Web server and the database on the same damn machine, and find it ridiculously overprovisioned while costing less than your incorporation.
I completely agree and advocate for that approach. That’s just not what the article is about.
[deleted]
-
> Building a scalable systems doesn't take extra time anymore,
Except you bleed money all over the place to do it this way.
AWS (and every other cloud provider) is still pricing its product like its 2013
> you just need an engineer who has experience doing it to lead the project
And then you become Figma, who probably should have gotten off of AWS before or with their IPO, rather than doubling down on AWS costs (something like 300k a day).
Most orgs who get past "survival" cant tell me the cost per user, or cost per customer or what each (named) customer is costing them in their stack. If they put in the effort to figure this out what they tend to find is that they are hemorrhaging money to third parties.
I know plenty of CTO's, vp's and Team leads and SR engineers who dont know what the rent vs buy calculation is, never mind how to do it. But I do know that AWS is what props up amazon and its value.
Except you bleed money all over the place to do it this way.
AWS (and every other cloud provider) is still pricing its product like its 2013
> you just need an engineer who has experience doing it to lead the project
And then you become Figma, who probably should have gotten off of AWS before or with their IPO, rather than doubling down on AWS costs (something like 300k a day).
Most orgs who get past "survival" cant tell me the cost per user, or cost per customer or what each (named) customer is costing them in their stack. If they put in the effort to figure this out what they tend to find is that they are hemorrhaging money to third parties.
I know plenty of CTO's, vp's and Team leads and SR engineers who dont know what the rent vs buy calculation is, never mind how to do it. But I do know that AWS is what props up amazon and its value.
Scale in this case isn't just about software scalability though, in the sense of RPS it can handle. It's:
- Don't build some automated support system until you get enough customers
- Don't build a fully automated provisioning system until it becomes a problem
- Don't build some fancy multi-region failover setup
- Don't worry about designing for some future feature that may or may not be needed
This doesn't mean write bad code though.
- Don't build some automated support system until you get enough customers
- Don't build a fully automated provisioning system until it becomes a problem
- Don't build some fancy multi-region failover setup
- Don't worry about designing for some future feature that may or may not be needed
This doesn't mean write bad code though.
Cloud is only a very limited and literal part of scalability
one of the greatest startup articles every written, thanks pg
So like moderation?
This is advice that has always sounded good to me on paper but not quite right in practice.
Scaffolding is great, until it isn't. It needs to be replaced with something resembling a Real Solution before the Last Responsible Moment comes and goes. But due to Hofstadter's Law as well as Queuing Theory, we can never get the timing right.
And so a lot of the devs you encounter who fight this have found themselves spending a lot of time throwing good money after bad, keeping a broken system working just enough that the customers don't defect, while trying to also find the time to replace the broken system, which is also always being made more difficult by the changes being made to keep the busted shit kinda working.
And so at some point they just say Enough. I'm not going to lie to myself and my coworkers by saying "We'll fix that later" because "later" never comes, only "too late" comes.
There are ways to spin this however. If the customer trusts that you know what you're doing and that you will eventually get to all of their problems, they'll stay put while you work on them. But you have to telegraph competence and then deliver on it. There's a needle you can thread there where you use not shipping systems that Don't Scale... ridiculously badly, you can tell the users to expect quality.
I will say this, as a compromise: It is almost always better to ship systems that scale too expensively than ones that don't scale at all - as long as that scaling leads directly to revenue. You're only shortening your runway by decreasing margins or taking them narrow. But if your customer base plateaus because you just can't onboard them anymore, what investor is going to float you more money to extend that runway?
I have always found it easier to negotiate priority on feature and story work that's attached to a new revenue stream (eg, new account) than ones that only reduce our OPEX. When the checks clear, a small but statistically significant amount of 'generosity' flows. You have to be ready though when it happens because the window is short.
Hey if we're going to land that Fortune 500 company, we need to work on ??? because they're likely to notice it sucks, if they don't just knock it over entirely in six months.
Scaffolding is great, until it isn't. It needs to be replaced with something resembling a Real Solution before the Last Responsible Moment comes and goes. But due to Hofstadter's Law as well as Queuing Theory, we can never get the timing right.
And so a lot of the devs you encounter who fight this have found themselves spending a lot of time throwing good money after bad, keeping a broken system working just enough that the customers don't defect, while trying to also find the time to replace the broken system, which is also always being made more difficult by the changes being made to keep the busted shit kinda working.
And so at some point they just say Enough. I'm not going to lie to myself and my coworkers by saying "We'll fix that later" because "later" never comes, only "too late" comes.
There are ways to spin this however. If the customer trusts that you know what you're doing and that you will eventually get to all of their problems, they'll stay put while you work on them. But you have to telegraph competence and then deliver on it. There's a needle you can thread there where you use not shipping systems that Don't Scale... ridiculously badly, you can tell the users to expect quality.
I will say this, as a compromise: It is almost always better to ship systems that scale too expensively than ones that don't scale at all - as long as that scaling leads directly to revenue. You're only shortening your runway by decreasing margins or taking them narrow. But if your customer base plateaus because you just can't onboard them anymore, what investor is going to float you more money to extend that runway?
I have always found it easier to negotiate priority on feature and story work that's attached to a new revenue stream (eg, new account) than ones that only reduce our OPEX. When the checks clear, a small but statistically significant amount of 'generosity' flows. You have to be ready though when it happens because the window is short.
Hey if we're going to land that Fortune 500 company, we need to work on ??? because they're likely to notice it sucks, if they don't just knock it over entirely in six months.
I think it's right in practice. Your first users are the kind of people who need something new and don't care if it's unscaled. They just need the new solution. You have to find the 1 person who needs the new thing you have, and it's the greatest filter stage for startups. Any time spent optimizing for the next 10 or 100 users is time spent wasted against looking for that 1 person.
12 year old article from a guy who built a web store platform in the 90’s and managed to position himself as a VC guru.
And yet here you are, commenting on his forum.
I had a friend who read this essay and understood it as “Don't do things that scale.”
I think there's nuance missing from his take that people gloss over.
To me it's more like "don't over-invest on the early thing you're going to throw away". That implies that:
- You're making a thing, and making it quickly - optimizing for rapid market/customer feedback
- You're making it in such a way that you can replace it
- You have real plans and a sincere intention to actually replace it if you start to scale
I have no problem with those, but what I see at a bunch of startups is:
- Make a thing, don't worry about paining yourself into a corner because "we're moving fast"
- The thing hobbles along, the product gets some interest
- It's incredibly hard to maintain, replace or otherwise improve
- Original authors leave to other pastures because this isn't fun any more
- Other folks come along and have to work miracles to try to undo the gordian knots that were made
In other words: I like the idea of moving fast early on. Duct tape programming, love it. We also have to pay attention to the long term impacts of the decisions we're making. Some things are easy to fix/replace/undo, others are brutally hard.
Say you write a prototype in {Ruby/Python/Perl/??}, now you have mass adoption and you rewrite a slow part of it in {sexy_modern_language}. That's great.
Say instead that you decided to store all of your data in some bizarre format, hosted on IPFS, accessed via bittorrent, through an onion network, via ZModem, with CORBA - and you bake this in to such a degree that it's intermingled everywhere. Now you have a dilema:
- you have a business, making money
- you have increasing interest
- you have a system that's effectively impossible to change or reason about
- you can't really improve things to match the customer interest
- you're wedded to the design because things are so interwoven
- your only option is essentially a ground-up redesign and rewrite
Now - if the product is simple enough, rewrite away! (think early Twitter), but if it's not? Good luck to you.
I've seen this pattern more times than I haven't, and I think it deserves more nuanced thought and care when it comes to the economics at play.
To me it's more like "don't over-invest on the early thing you're going to throw away". That implies that:
- You're making a thing, and making it quickly - optimizing for rapid market/customer feedback
- You're making it in such a way that you can replace it
- You have real plans and a sincere intention to actually replace it if you start to scale
I have no problem with those, but what I see at a bunch of startups is:
- Make a thing, don't worry about paining yourself into a corner because "we're moving fast"
- The thing hobbles along, the product gets some interest
- It's incredibly hard to maintain, replace or otherwise improve
- Original authors leave to other pastures because this isn't fun any more
- Other folks come along and have to work miracles to try to undo the gordian knots that were made
In other words: I like the idea of moving fast early on. Duct tape programming, love it. We also have to pay attention to the long term impacts of the decisions we're making. Some things are easy to fix/replace/undo, others are brutally hard.
Say you write a prototype in {Ruby/Python/Perl/??}, now you have mass adoption and you rewrite a slow part of it in {sexy_modern_language}. That's great.
Say instead that you decided to store all of your data in some bizarre format, hosted on IPFS, accessed via bittorrent, through an onion network, via ZModem, with CORBA - and you bake this in to such a degree that it's intermingled everywhere. Now you have a dilema:
- you have a business, making money
- you have increasing interest
- you have a system that's effectively impossible to change or reason about
- you can't really improve things to match the customer interest
- you're wedded to the design because things are so interwoven
- your only option is essentially a ground-up redesign and rewrite
Now - if the product is simple enough, rewrite away! (think early Twitter), but if it's not? Good luck to you.
I've seen this pattern more times than I haven't, and I think it deserves more nuanced thought and care when it comes to the economics at play.
It's easier to figure out a way to scale something that is working than trying to fix a scalable approach that's falling flat.
If you are going to be VC funded. Yes, absolutely. All you need is smoke and mirrors. And the ability to project confidence about what is otherwise an absolute fantasy that doesn't yet exist. Which is what many startups are until they get their house in order (with VC funding). Sometimes VCs get it right and they'll bore you endlessly about their successes. But the 95% that fail that they also invested in and probably shouldn't have is what they generally don't talk about a lot other than in terms of vague hints about acquihires, mergers, and other tried and proven strategies to make a bad investment look like a good one. The unremarkable airbnb clone, the tinder for X, Y, and Z that never panned out. The too good to be true yet-another market place that amounted to little. All of those.
If you are bootstrapping with revenue instead of money, customers won't be lining up for a product that won't work. They won't be interested in your self serving story about how you built the thing with duct-tape and mud while surviving on ramen noodles without sleeping for five months. That would scare them away probably. You actually need to build something that they would 1) buy and then 2) be happy about buying. And you won't have any VC donated cash to wow/lure/distract them with marketing either. You actually need to sell on product merit rather than founder reputation instead of using your reputation to separate VCs from their cash just so you can get the resources you need to not fake the product. Once the product has proven itself, the VC is redundant.
It's a very different game. Most of the things that work with VCs won't work with customers. And vice versa (you are going to slow, you should be focusing on X instead of Y, and all the other nonsense).
But the good news is, you won't need to scale for a while because bootstrapping isn't a fast process. The bad news is that you might not have a lot of time to fix your scaling issues when you do encounter them and they can and will sink your company if you can't. But the good news is that VCs might show up again that time. The bad news for them is that at that point they are generally too late to make a lot of money and will lose interest. You need a different type of investor at that point. It helps to not have too many huge scaling issues when you finally manage to convince customers that buying your thing is a good idea.
Figuring out the right balance between scalability and utility and when to focus on what is a judgment call in the end. Boring tech is usually a good call. Unless the tech is the main thing that you are selling. But don't let a VC tell you. They are just trying to get you to the 95% quickly just in case you don't make their 5% cut. All this business about scaling, keeping customers happy, etc. is just a distraction. It takes too much time. That could take years. They want months/weeks. They'll be happy to write investments off quickly. That doesn't mean it was a bad investment or plan.
VCs want unicorns or nothing. It's high stakes gambling. Most of the economy is a very different kind of business. There's nothing wrong with building a decent business with your hands and creativity.
If you are bootstrapping with revenue instead of money, customers won't be lining up for a product that won't work. They won't be interested in your self serving story about how you built the thing with duct-tape and mud while surviving on ramen noodles without sleeping for five months. That would scare them away probably. You actually need to build something that they would 1) buy and then 2) be happy about buying. And you won't have any VC donated cash to wow/lure/distract them with marketing either. You actually need to sell on product merit rather than founder reputation instead of using your reputation to separate VCs from their cash just so you can get the resources you need to not fake the product. Once the product has proven itself, the VC is redundant.
It's a very different game. Most of the things that work with VCs won't work with customers. And vice versa (you are going to slow, you should be focusing on X instead of Y, and all the other nonsense).
But the good news is, you won't need to scale for a while because bootstrapping isn't a fast process. The bad news is that you might not have a lot of time to fix your scaling issues when you do encounter them and they can and will sink your company if you can't. But the good news is that VCs might show up again that time. The bad news for them is that at that point they are generally too late to make a lot of money and will lose interest. You need a different type of investor at that point. It helps to not have too many huge scaling issues when you finally manage to convince customers that buying your thing is a good idea.
Figuring out the right balance between scalability and utility and when to focus on what is a judgment call in the end. Boring tech is usually a good call. Unless the tech is the main thing that you are selling. But don't let a VC tell you. They are just trying to get you to the 95% quickly just in case you don't make their 5% cut. All this business about scaling, keeping customers happy, etc. is just a distraction. It takes too much time. That could take years. They want months/weeks. They'll be happy to write investments off quickly. That doesn't mean it was a bad investment or plan.
VCs want unicorns or nothing. It's high stakes gambling. Most of the economy is a very different kind of business. There's nothing wrong with building a decent business with your hands and creativity.
(2013)
[deleted]
[deleted]
Cherry-picks winners: Uses only successful examples like Stripe or Airbnb while ignoring thousands of failed startups that tried identical manual tactics.
False choices: Presents manual work vs. scalable strategy as either/or when most successful companies do both simultaneously.
Has a One size fits all: Claims all startups must recruit manually, ignoring that enterprise products need fundamentally different approaches.
Instead, do the following...
- Interview failed founders, not successful ones: They will tell you why things actually break (co-founder fights, cash flow, timing) instead of survivorship bias fairy tales.
- Optimize for "no," not "yes": Ruthlessly eliminate wrong customers instead of trying to delight everyone. False positives kill more startups than missed opportunities.
- Plan your failure modes first: Map exactly how you could die (regulation, key person risk, moats) and build defenses. Most founders only plan for unicorn outcomes.
- Copy boring businesses, because that is the secret of sucess. Dont copy sexy startups: Uber is just taxis with an app, Airbnb is hotels with no real estate, Netflix is just video rental with better logistics. The biggest "innovative" companies are doing boring businesses better, not inventing new categories.
False choices: Presents manual work vs. scalable strategy as either/or when most successful companies do both simultaneously.
Has a One size fits all: Claims all startups must recruit manually, ignoring that enterprise products need fundamentally different approaches.
Instead, do the following...
- Interview failed founders, not successful ones: They will tell you why things actually break (co-founder fights, cash flow, timing) instead of survivorship bias fairy tales.
- Optimize for "no," not "yes": Ruthlessly eliminate wrong customers instead of trying to delight everyone. False positives kill more startups than missed opportunities.
- Plan your failure modes first: Map exactly how you could die (regulation, key person risk, moats) and build defenses. Most founders only plan for unicorn outcomes.
- Copy boring businesses, because that is the secret of sucess. Dont copy sexy startups: Uber is just taxis with an app, Airbnb is hotels with no real estate, Netflix is just video rental with better logistics. The biggest "innovative" companies are doing boring businesses better, not inventing new categories.
> - Interview failed founders, not successful ones: They'll tell you why things actually break (co-founder fights, cash flow, timing) instead of survivorship bias fairy tales.
I like this idea a lot, if it can be done well.
Is there already trove of failed tech startup stories that are genuine, and maybe analyzed like business case studies? Is it publicly-accessible, or could it be?
I think the biggest challenge is getting truthful and complete information. (People will have made embarrassing mistakes, no matter how much brilliant heroism the team also pulled off. There will be things the failed founders don't want past customers/partners/investors to know. There will be things investors don't want known about their own behavior. For growth startups, there may be investment fraud at some level, for example. Or backstabbing. There will be differences of perspective on what really happened. There may be personality disorders. Etc.)
A lot of people will tolerate a disposable "incredible journey" post to put a less-negative spin on failure, but AFAICT usually no one involved really wants all the truth to get out.
Also, if you do it, ideally it would be for all startups. If you only do it for some, without all being humbled simultaneously, then current convention is to look down upon those with the transparency, while pretending the non-transparent ones are better. It's a pretty dim-witted and petty culture, and we have to structure with that in mind.
I like this idea a lot, if it can be done well.
Is there already trove of failed tech startup stories that are genuine, and maybe analyzed like business case studies? Is it publicly-accessible, or could it be?
I think the biggest challenge is getting truthful and complete information. (People will have made embarrassing mistakes, no matter how much brilliant heroism the team also pulled off. There will be things the failed founders don't want past customers/partners/investors to know. There will be things investors don't want known about their own behavior. For growth startups, there may be investment fraud at some level, for example. Or backstabbing. There will be differences of perspective on what really happened. There may be personality disorders. Etc.)
A lot of people will tolerate a disposable "incredible journey" post to put a less-negative spin on failure, but AFAICT usually no one involved really wants all the truth to get out.
Also, if you do it, ideally it would be for all startups. If you only do it for some, without all being humbled simultaneously, then current convention is to look down upon those with the transparency, while pretending the non-transparent ones are better. It's a pretty dim-witted and petty culture, and we have to structure with that in mind.
Read this and you will learn a lot more:
"Failed Startups- +70 articles listing +400 failed startups, filtered by country, industry, customer, and cause of failure" - https://www.failory.com/failures
"Failed Startups- +70 articles listing +400 failed startups, filtered by country, industry, customer, and cause of failure" - https://www.failory.com/failures
Thanks. That site is advertising-heavy, but does have some info. One thing that could be done better is that the interviews I skimmed are softball to one person. So this is more the "incredible journey" answer for why it failed, but the actual dozen unflattering reasons.
Agree a little bit. Here is another one:
"483 startup failure post-mortems" - https://www.cbinsights.com/research/startup-failure-post-mor...
The exceedingly tidy high-level explanations might be OK for some purposes, but not so for actually avoiding the contributing factors happening again to countless startups in the future.
I wonder whether anyone at any investment firm bothers to understand why a startup actually failed, or that's irrelevant to their operating model.
I wonder whether anyone at any investment firm bothers to understand why a startup actually failed, or that's irrelevant to their operating model.
I agree with your comment as an additional way to look at the problem but want to also mention something I heard on a podcast a few months ago.
Paraphrasing "If you get good at seeing red flags it doesn't make you good at seeing green ones. When you optimize against failure you don't optimize for success. So on and so forth."
A failed founder can tell you what broke but won't know what else could've gone wrong or rather what else they needed to go right.
Paraphrasing "If you get good at seeing red flags it doesn't make you good at seeing green ones. When you optimize against failure you don't optimize for success. So on and so forth."
A failed founder can tell you what broke but won't know what else could've gone wrong or rather what else they needed to go right.
This is true. Skepticism can keep you free from mlm scams, but that same trait will keep you from buying bitcoin when it's at .0001 cents.
This is AI.
Graham reads Taleb
updatepriors(2)
positron26(1)