[shin_lao]

Seeing a lot of people shit on Paul, which I guess, why not, but it's not super useful or positive.

I think this is a fairly good essay which can be boiled down to "don't do premature optimization" or "don't try to behave like companies much bigger than you".

There are three advantages to this:

1/As a founder, get your hands dirty, even if in the grand scheme of things it's inefficient. You'll get first hand experience and feedback. 2/Avoid the upfront cost of "something that scales", and thus get quicker feedback. 3/Makes you different, very important in the beginning.

"Do things that don't scale" is a way to drive the point home and must not be taken literally...

[nine_k]

Many people are concerned with becoming an overnight success and being unable to withstand the load, and losing the momentum. So they build highly scalable things before the slightest need for horizontal scaling even arises.

I think that vertical scaling is underappreciated. Just throwing more resources at your monolithic backend can buy you quite enough time to understand how to best scale your product. More importantly, it may give you the time to reconsider what are the key strengths of your product that the users are for, and thus to understand what needs scaling.

Also, when users really love your product, they will excuse you for its spotty performance. Early Twitter was built on a hugely inadequate architecture (a Rails app), and kept melting and crashing; remember the "fail whale"? Despite that, users were coming to it in droves, because it did the key things right.

To my mind, the early stage is all about easy iteration and finding out what makes users happy and enthusiastic. Ignore scaling; experiment, listen to the users, talk to the users. When it clicks, you can consider scaling. It may happen at a point you did not anticipate, and could not optimize for.

Technology is a tool, an instrument. It's great to have a Stradivarius, but you need some good music first.

[datadrivenangel]

Pets.com died because they scaled too fast and couldn't handle the load and didn't have the cashflow to fill orders.

It's a valid concern, but most people radically overestimate the likeliness.

[al_borland]

It’s also important to realize that not every successful or worthwhile business has millions or billions of users that requires extreme optimization and scalability.

I work on internal tools at my company. We know how big our environment is, there isn’t much sensitivity to performance, and we don’t see random spikes that we don’t cause ourselves. Yet I had someone on my team who was obsessed with optimizing everything, to the point of changing his entire code base to a new language that only he knew, so he could save a few milliseconds on paper. Aside from him, no one noticed, no one cared. His optimizations just introduced risk, as he was the only one who could support what he built. When he left, we threw the whole thing away at management’s demand. Had it been a little more simple and slow, someone else probably could have taken it over without as much effort.

[skydhash]

My own ethics is mostly about collaboration and confidence. I make sure that I’m ready to offload work whenever I want, and knowing what I ship is working. Other thing are just fun experiments. If it does not impact positively the business/consumers, I’m very happy to not do it. God knows that there’s always something to work on that does.

[sneak]

> "don't try to behave like companies much bigger than you"

This is such good advice for organizations at all stages. As a consultant I spend a lot of time talking startups and small companies out of hobbling themselves by adopting policies they think they have to simply because they're a corporation, when those policies only make sense when you have at a minimum hundreds of people involved in the org.

Everything from k8s to nosql to overly restrictive security policies. The Netflix employee handbook/guide really drove this point home to me. When you're small, and you're hiring well, you can afford to actually delegate real responsibility to your staff and let them use their judgement. Not everything needs to be a hard and fast rule until and unless there's an unacceptable level of risk or a demonstrated problem at hand.

[tempestn]

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.

[nonethewiser]

There is a key difference from "don't do premature optimization." "Premature optimization" suggests the scaled version is optimal. It might not be worth the resource cost to achieve it, but disregarding that, its the best.

Whereas "Do things that Dont Scale" is suggesting the non-scaled process may be the optimal one. For example (and this sort of thing is in the article IIRC), giving direct contact details to the CEO instead of a generic form that get's sent to some shared customer service/sales inbox. Way better process for selling your product. The inquiry form scales but its in no way a premature "optimization."

Another way of putting it is that SCALING IS BAD. Or to be a bit more nuanced, it's a necessary evil. It's complex. It's resource intensive. It creates distance between you and your customer. Of course business goals and environment may dictate it, but that doesn't mean none of the processes are degrading in quality. So its more like dont do "premature process degradation" than "premature optimization" I think.

[chairmansteve]

Or boiled down to "don't solve problems you don't have".

[begueradj]

> "don't try to behave like companies much bigger than you"

That's a good point.

[paulddraper]

A lot of people have not built a successful company either.

[qualeed]

>Seeing a lot of people shit on Paul

Hardly "a lot". There's like three negative comments and one of them is strictly criticizing the article itself and not paul. I thought it brought up some good points.