Do things that don't require scale | Hacker News Reader

Do things that don't require scale

davidnicholaswilliams.com

156 pointsdavnicwil43 comments

That's what the book "Black Swan" by Nasem Taleb recommends as well. Basically, he says that if you're working on something that working on things that depend on a huge scale, they also require a huge amount of luck for it to work out, compared to to thinks that don't require scale, which are more likely to be succesful based on the amount of work put in. There's a smaller opportunity for large reward, but a larger chance of getting any reward period.

Oh man; you just thoroughly obfuscated THE single most important insight from the book. This is a must to understand;

Mediocristan(non-scalable) vs. Exremistan (scalable) - https://kmci.org/alllifeisproblemsolving/archives/black-swan...

What you should do is stop listening to people who tell you what to do.

You can't tell me what to do!

I was doing that, but now thanks to you I have to stop.

I know you're being jokey, but there's no contradiction here. Not listening != doing the opposite.

Let us never forget that some people enjoy doing things the hard way, whether it is pragmatic or not. Things are built by people and people will always build their personal idiosyncrasies into their projects. They will over-engineer things to scale that do not actually need to scale.

people are often wrong, too. Decisions made "because it will scale later" usually optimize for the wrong thing, and you have some completely other scaling problem that is made worse by the early "optimizations"

> A common root of the issue, I believe, is looking at already successful products and imagining how they could be iterated upon or diverged from in new and interesting ways. Such divergent ideas are often very reasonable, good even, the problem is that they require the same scale to work as the products they are based upon.

This assertion just assumes there's no room for optimization and / or improvement on already commercialized products and that the originating company got everything right in the first place.

A product can be sold a ton of ways. Slights tweaks to the strategy and / or to the product itself can sometimes be game changing.

That's not because a product is successful at huge scale that it can't be successful at smaller scale.

> This assertion just assumes there's no room for optimization and / or improvement on already commercialized products and that the originating company got everything right in the first place.

It's not saying the improvement isn't an improvement, it's just saying that the improvement is useless until you reach sufficient scale.

That's not always a nonstarter. Truly new work might involve establishing an entire supply chain for a product line. Followers can reuse some of your work, if you haven't locked up all of the capacity.

Commoditization of your complements stops your complements from competing with you, but also opens you up to other competitors.

This article would be much better if it gave some specific examples.

Thanks for this. I thought about adding some examples but really the goal of the article is more for readers to apply a lesson I’ve learned the hard way to their own ideas, so instead I went for a more general set of ways to think about if their idea might require scale to work, rather than demonstrating via concrete examples.

That depends on what you mean by "require" - one successful startup strategy is to make something that _functions_ for a small user base, but operates at a loss until it hits some critical size. Like, in the early days at Square, we lost money on literally every transaction, but as the number of transactions increased it was possible to negotiate a bulk processing rate, (and then much, much later scale the number of transactions high enough to pay for the engineering department). But the customers saw value immediately, and the trajectory was convincing enough for investors to provide the bridge.

Based on the article, I believe the author would say that Square is an idea that requires scale, since you "lost money on literally every transaction, but as the number of transactions increased..."

I might be misunderstanding something, but it seems that Square becoming profitable required reaching a certain scale.

I guess I'm trying to split a hair here, but I feel like some ideas don't even minimally work until there's a critical number of users. Like if you're building a user-contributed database of any kind, it has to be useful at the small size before or else it won't ever grow to be useful at a large size. I feel like I've heard pitches that only talk about the large size. And that process is sometimes separate from the more "business" concerns of cost versus profitability. IDK, the author wasn't totally clear about what domain we were talking about here.

you just helped me understand that the key is probably to very quickly understand whether the thing you're building can remain sustainable without scale, or absolutely needs to hit scale so it can be sustainable, and like you said that hasn't been distinguished in this article...

idk like in my head building a personalized black car service vs. building a bus-service fundamentally requires different conversations around scale b/c of the different domains

This reminds me of something I used to say:

"I'd rather build something with 1000 paying customers instead of 1,000,000 free users"

(... who I'd eventually have to try and monetise in uncomfortable ways)

like the GIF normally says why not both?

income from the 1000, worldly impact from the 1000000.

All depends how much energy or resources you have at hand to deal with them.

In my experience, 'free' users can often be far more demanding (and draining) to deal with. While this is obviously some value to garnered from them, they can rapidly suck the life and passion out of a system or network, to the detriment of those who have paid, which can then create dissent from actual 'customers'.

I feel like all (software-y) business ideas that don't require scale would fall under some form of "consulting". Does anyone disagree with this?

Does this mean something more than "all software is either generic (scale) or specific (consulting)?"

You're thinking about scale in a different sense.

> You can do things that don't scale to accelerate a good idea, but by definition you actually can't do that if the idea itself requires scale. The idea has to work on day 1, for customer 1.

He's talking about ideas that only work if the company has scaled to some non-trivial size of users or some other relevant factor. Uber would be an example. How could Uber work if there was only 1 customer? There would be no drivers.

If you need to "do things that don't scale" to launch your idea, your idea probably also needs to work with low scale of users/revenue/investment or you will be dead in the water.

Wouldn't you call that a network effect? Uber is only effective if you build up a network of customers.

I thought scale meant you could run your service for 1 million users just as easily as you can run it for 1,000 users.

Yes I'd call it a network effect, and the author does as well later in the article. The point is that the network effect is required for the idea to work. It doesn't have to be a network effect though. Other examples he gives:

> Third, how synchronous and mission critical is it? Be skeptical if it going down would cause interruption to workflows that couldn't be worked around or deferred. Be incredibly skeptical if this is true round the clock and on weekends. That kind of service level implies significant and robust automation and support, which require scale.

> Fourth, how much does the business model depend on volume? Losing a bit of money on first customers as you bootstrap and learn is not an issue. Be skeptical, though, if this would need to be sustained to bootstrap your way to some required volume which is quite a way beyond those first few customers.

Generally I also think of technical scale first, but I think using it more generally here is valid.

A number of SaaS businesses can make a few million a year with small teams and smaller server counts.

Like starting a food truck?

Food trucks may need to scale because you have to buy additional food, maybe hire a few additional people.

No lemonade stand, unless you already have the lemons.

You'd think blogging on a free platform might fit the bill. But, making money depends on readers, which would need to scale to make ads worthwhile, so scratch that- it's scale-dependent. Don't do that.

Maybe if your family has a lot of money, you could pay someone to write your app for you. No- scratch that- it's dependent on the number of people paying for it, and you need to buy ads to reach them, so it must scale.

You could be an investor! Just hold out a carrot and watch people work themselves to death while having a small chance at success. Even if only 1 in 10 you end up actually giving money to for their work are successful, you come out on top. Wait, it turns out 1 in 10 isn't guaranteed. That won't scale, then.

Instead of investing yourself, have someone else invest it for you. Nevermind, no one would do that, because in order for it to be worth it for someone to invest for you without taking too much off the top for overhead, they'd have to scale.

Back to selling.. you could sell your existing possessions and evengelize, going from place to place to get food and lodging.

Sounds a lot like being a priest.

A Food Truck can be a good study of scale.

Every sale should make some money and the scale can determined by fixed costs divided by the net profits per sale - if your equipment lease costs $30 per day, and you sell a burger for a net $1, you must sell 30 burgers per day.

If you maximize profit margins, vertically integrate as much as possible ( hello family labor ) and really dig in to your customer base to find a great fit that they are willing to pay good margins for, then you don't have to sell a million burgers from a hundred trucks to take a weekend off.

The statement was about "not requiring scale" to be viable - not about scaling itself. Scaling is fine - "having to scale" before the money runs out is not.

A slightly different take: do things in such a way that scaling isn't a consideration. Figure out if you want to scale or not, and make a thing that either scales, or doesn't. Don't make a thing and then get surprised later. And don't make a thing a particular way just because people tell you to. Know what you're getting yourself into, and then jump in with intention.

The whole "things must scale" made sense 20 or 10 years ago. But today there is so much competition and free capital. New business is lucky if it carves out small niche and turns profitable.

The same with hardware. We had tiny machines comparable to Raspberry Pi 4 hooked in cluster. Today you can rent single server with 24TB DDR RAM and countless SSDs.

of course you could argue that this situation has only happened because things "above you" have scaled (up, by a lot).

In the time since the dotcom boom, the magnitude of Metcalfe's Law has been argued.

Last I heard, the argument was that the effect for social networking was closer to nlogn than n^2. If true, then quadrupling in size may increase the value by some number of percentage points instead of an order of magnitude.

Which means 'big enough' may not be that big.

Yea, I mean, handling scale is such a specific issue and everyone worries about it too much. At this point, you just use DynamoDB or some other managed service, and let the teams with 1000's of developers worry about scale.

Reminds me of this very controversial but incredible talk by @DHH of Basecamp/Hey: https://www.youtube.com/watch?v=MlhAkNWC1qo&lc=Ugiz_Gf7IfVGP...

Things that don't require scale require a VERY different line of business thinking, generally centered around profits vs growth.

I would also add:

- don't do anything that is based on user-generated content(email, social network, ...)

- it cannot be anything the customer can make himself on his own(e-commerce website with woocommerce, payments with stripe, data storage with s3 ...)

- a NEW idea must be monetizable from the get-go to avoid big players coming in and taking over in shorter time than it takes you to get up and running and building a customer base

- it must be a new idea that has no market yet or existing players have insufficient offering

- if you cannot draw the idea on one A4 paper, the idea is too complicated

- if the price of switching providers is too low, you will lose customers when new players come in and vice versa if you are entering existing market

- if you cannot put out MVP in three months, the idea is too complex

- if the MVP(or even production version) software product/service cannot run on one single VPS or bare-metal server, it is way too complex

- if implementing gdpr and alike are too complicated, the idea is too complicated

- you should avoid storage of any user-generated sensitive information(invoices, payment/transaction details, passwords, keys...), sooner or later it will bite you in the ass

I have recently talked about the world of startups being done for since many large companies offer services for free, even if it is not their core business, they prevent new players form entering the market and pump up their stock by adding value to their name. If you have something new, the big players can take over the entire market whenever they want. Doing something simple worked in 2000s but nowadays a single developer cannot do what was passible back then and you need a team, and as mentioned above, massive financing to be fast to market. So essentially the world belogns to large corporations these days :(

> many large companies offer services for free

Yes, indeed - free on its own isn't always impossible to compete with, you can often compete on features and quality.

But a combination of free and at scale is formidable, because of the bundling with other services, branding and marketing that scale allows.

I don't believe in listing advice. One advice is useful when used in a specific context and bad in other contexts. When you list advice, you make it sounds like this is a path to follow.

Well for any thing that you tell people to not do, you will have people who succeed by doing it, and vice versa.

List of advice are just random sentences that don't mean anything

Fantastic irony here ;)

"So essentially the world belogns to large corporations these days :("

This is not a change at all. Large companies buy smaller ones. Large companies buy markets. This is nothing new, and it creates a lot of startup opportunity. Feature purchases, mergers, roll-ups and even acquihires can create wealth for founders and investors. Not every company has the timing and resources to be a Facebook or Google, but their are so many other big success stories. Keep on trying, don't give up, and don't let arbitrary rule lists stop you.

>oing something simple worked in 2000s but nowadays a single developer cannot do what was passible back then and you need a team, and as mentioned above, massive financing to be fast to market.

I would like to add to this that our tooling has also seen massive improvements, which in turn greatly boosts the leverage of each individual contributor. For e.g. A single person can throw together a rudimentary web-browser in a week by leveraging existing components/tools/etc. Not to mention other benefits like easy access to experts via online forums, automated testing frameworks, etc, etc.

You are contradicting yourself. First you argue ideas should be simple, and then argue simple ideas do not work anymore.

> if you cannot put out MVP in three months, the idea is too complex

> Doing something simple worked in 2000s but nowadays a single developer cannot do what was passible back then and you need a team

Reply on news.ycombinator.com