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.

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.

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 :)

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 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.

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)

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 the very first post I saw on Hacker News.

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.

I don’t know how people are thinking this is about scaling web application capacity unless you are responding to the title.

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.

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

I wonder if Paul has a take about the same in this era of AI

Relevant discussion thread https://news.ycombinator.com/item?id=38010992

-

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.

one of the greatest startup articles every written, thanks pg

So like moderation?

I had a friend who read this essay and understood it as “Don't do things that scale.”

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.

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.

(2013)

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.

[dead]

Graham reads Taleb

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]