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, 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.
shin_lao · 1h ago
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 · 37m ago
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.
nonethewiser · 47m ago
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.
al_borland · 1h ago
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 · 54m ago
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.
sneak · 36m ago
> "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 · 39m ago
A lot of people have not built a successful company either.
begueradj · 44m ago
> "don't try to behave like companies much bigger than you"
That's a good point.
qualeed · 1h ago
>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.
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 · 2h ago
This was the very first post I saw on Hacker News.
Glad to see it reposted every now and then. Makes me nostalgic.
pinkmuffinere · 1h ago
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.
I wonder if Paul has a take about the same in this era of AI
OtherShrezzing · 2h ago
>Scale things that don’t do
Jabrov · 2h ago
This is the best comment I’ve ever seen
chubot · 1h ago
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
psychoslave · 1h ago
I rarely do comments just to say thank you for the great laugh, but when I do, I do it on HN.
raincole · 1h ago
I'm really, really surprised that no one has made this joke on HN so far after ~2.5 years of AI hype.
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.
laserlight · 1h ago
I had a friend who read this essay and understood it as “Don't do things that scale.”
switchbak · 39m ago
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.
pbardea · 50m ago
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.
jillesvangurp · 1h ago
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.
fHr · 34m ago
Bro the amount of job ads with just requiring 20yoe on scalable 20 million aum apps lol
pyrale · 2h ago
(2013)
belter · 1h ago
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.
mavilia · 53m ago
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.
aswanson · 11m ago
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.
neilv · 38m ago
> - 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.
lurk2 · 40m ago
This is AI.
scoofy · 1h ago
Graham reads Taleb
fHr · 33m ago
Also holy fucking necro
positron26 · 2h ago
[flagged]
dang · 45m ago
Can you please not post comments like this? We're trying for something (significantly) better on this site.
You may not owe whoever you're complaining about better, but you owe this community better if you're participating in 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, 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.
I think this is a fairly good essay which can be boiled down to "don't do premature optimization" or "don't try to behave like companies much bigger than you".
There are three advantages to this:
1/As a founder, get your hands dirty, even if in the grand scheme of things it's inefficient. You'll get first hand experience and feedback. 2/Avoid the upfront cost of "something that scales", and thus get quicker feedback. 3/Makes you different, very important in the beginning.
"Do things that don't scale" is a way to drive the point home and must not be taken literally...
I think that vertical scaling is underappreciated. Just throwing more resources at your monolithic backend can buy you quite enough time to understand how to best scale your product. More importantly, it may give you the time to reconsider what are the key strengths of your product that the users are for, and thus to understand what needs scaling.
Also, when users really love your product, they will excuse you for its spotty performance. Early Twitter was built on a hugely inadequate architecture (a Rails app), and kept melting and crashing; remember the "fail whale"? Despite that, users were coming to it in droves, because it did the key things right.
To my mind, the early stage is all about easy iteration and finding out what makes users happy and enthusiastic. Ignore scaling; experiment, listen to the users, talk to the users. When it clicks, you can consider scaling. It may happen at a point you did not anticipate, and could not optimize for.
Technology is a tool, an instrument. It's great to have a Stradivarius, but you need some good music first.
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.
I work on internal tools at my company. We know how big our environment is, there isn’t much sensitivity to performance, and we don’t see random spikes that we don’t cause ourselves. Yet I had someone on my team who was obsessed with optimizing everything, to the point of changing his entire code base to a new language that only he knew, so he could save a few milliseconds on paper. Aside from him, no one noticed, no one cared. His optimizations just introduced risk, as he was the only one who could support what he built. When he left, we threw the whole thing away at management’s demand. Had it been a little more simple and slow, someone else probably could have taken it over without as much effort.
This is such good advice for organizations at all stages. As a consultant I spend a lot of time talking startups and small companies out of hobbling themselves by adopting policies they think they have to simply because they're a corporation, when those policies only make sense when you have at a minimum hundreds of people involved in the org.
Everything from k8s to nosql to overly restrictive security policies. The Netflix employee handbook/guide really drove this point home to me. When you're small, and you're hiring well, you can afford to actually delegate real responsibility to your staff and let them use their judgement. Not everything needs to be a hard and fast rule until and unless there's an unacceptable level of risk or a demonstrated problem at hand.
That's a good point.
Hardly "a lot". There's like three negative comments and one of them is strictly criticizing the article itself and not paul. I thought it brought up some good points.
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)
This was 12 years ago. Even he couldn't have imagined how successful it would still become. I wish there were I way I could have invested in it.
Glad to see it reposted every now and then. Makes me nostalgic.
Edit: business is mydragonskin.com
https://news.ycombinator.com/item?id=38019292
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
Congrats. You won HN today.
https://news.ycombinator.com/item?id=44913240
for him...
https://xkcd.com/1683/
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.
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.
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.
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.
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.
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.
You may not owe whoever you're complaining about better, but you owe this community better if you're participating in it.
https://news.ycombinator.com/newsguidelines.html