Building for Scale - Understanding the Why

You have all heard the adage “do things that don’t scale.” It’s a good one - when scaleability is the key thing that drives your decision-making, you will always revert to the lowest common denominator solution. Listen, maybe sometimes that’s the right solution but you don’t know if you don’t start by aiming high and trying to start by doing something incredible. We talk about how functional isn’t good enough; it needs to feel magical. That feeling of magic is what we’re pursuing when we talk about doing things that don’t scale. It makes the user feel like they’re a part of something special and remarkable.

The danger of “do things that don’t scale” is when you have captured that magic lightning in a bottle and now you actually do have to scale it. There are 3 challenges you may run into in this moment:

1. You’ve fallen in love with your unscaleable solution
2. You don’t know why your users have fallen in love with your unscaleable solution
3. You can’t even imagine how it could scale in the first place.

So let’s talk about the way out of each of these. I’m actually going to run through them in reverse...the third one is just the result of a myth, which is that in doing things that don’t scale you should never think about how they might scale. It’s true that for some people, they need to be fully released from the burden of thinking about scale in order to come up with a brilliant idea...but once you have that brilliant idea, and you’re starting to build it, scale shouldn’t drive your decision-making but you should still leave yourself little hooks that you can scale on top of. Know where your potential points of scaling friction might be, and already have some ideas in your mind about how you could overcome them.

I think the most daunting of the challenges is the second one: you don’t know why your unscaleable solution has become magic. This one is the most dangerous, because if you don’t know, you can’t put other options in play to achieve that magic, so all you can do is try to take your existing unscaleable solution and by brute force make it scale. This doesn’t end well - it almost always ends up killing the magic because it wasn’t intended to scale as it was in the first place. There are a few ways around this one: your intuition, your users, and your alternatives. Your intuition just involves actually explaining why you thought it would be magical in the first place. Your users involves talking with your users and understanding what about it they really love. Your alternatives just means taking what you learn in those first two steps and asking yourself, “what other ways are there that I can accomplish this?” There’s always more than one way to skin a cat. Often, doing this can even allow you to identify a way to increase the magic as you scale because you understand the why.

I saved “falling in love with your unscaleable solution” for last because if you’ve addressed the first two challenges, it becomes a lot easier to fall out of love with your solution because you can see other ways to approach the solution. You have to tell yourself: keeping your unscaleable solution means killing your unscaleable solution, because your unscaleable solution isn’t good enough. It has to be able to scale. Go back to problem 2 and figure out what it is you love about it, and do your damnedest to preserve that.