Do you think about scale early on?

I do think about scale in terms of product. IE: will my offering still work when I sell 1000 logos a day? I needed to find an answer to that to feel comfortable building it.
But in terms of engineering I wouldn’t worry about it. Just pick whatever your fastest with. I made the mistake of starting with new fancy tech, and delayed launch for months just because I wanted code to be perfect. When we finally launched it all became clear how useless it was. All that matters is to build features that people wants, the rest is superficial. Now I have a shitty codebase (for my standards, being a dev for 15years) but I’m happy, because I can move fast. We’ll rebuild when we have money to hire a dev!

I think about it. I guess as engineers we do even if we don't want to :).

But I don't do any real action, because it makes no sense.

Your product is likely too small for real scale. Perhaps forever. It's a mistake to optimize for it.

Now that does not mean building a slow product, prevent N+1 queriers, or optimize assets. It means not deploying Kubernetes from the get go, or worry that your Ruby app should have been written in Java.

I think it's only natural to think about scale very early in a project: it's part of the daydream of success. As we sit idly picturing the future, of course our product is going to be successful, and of course we're going to need to handle tremendous scale.

But scaling is a tactical exercise and should be based on evidence. The question to think about is: what do you need to scale? Without traffic or a significant number of users, how do you know which parts of your application need to be optimised?

Personally, I try to make pragmatic decisions early that I know could be optimised in the future. This is a technical debt, but that's fine as long as you have a clear idea of how you would pay this down later.

Thanks for the overwhelming responses. This does help with the confidence. Some of the takeaways I get from this is:

• Focus more on marketing and getting customers rather than thinking about scale early
• Pick a decent framework or tech stack that at least has the flexibility when you have the need to scale.
• Idea validation is important. Focus more on Idea rather than scale and scale when you have the need.

I always ensure my product can handle 2-3x growth overnight. But that’s it.

This works really well because it scales with how big your product currently is. If you have 10 users it’s not difficult to test if it will work for 20-30.

Odds are you won’t have to do much of anything.

If you have 1000 seeing if it works for 2000-3000 shouldn’t be much more work. And so on.

This leaves you some wiggle room for if you do go a little viral.

It won’t account for, for example, a successful Product Hunt launch. But if you know you might get a huge influx of users overnight then you can test for that scenario then, and not earlier.

Trying really really hard to quite that part of the lizard brain down.

Premature optimisation
👿

From an engineering point of view, you should think of scale early on. For certain things. There are costly mistakes you can make early on using providers and infrastructure which won't scale.

The main issue is vendor/service lock in. You need to think carefully about implementing 3rd party providers as a core part of your service. Does the pricing scale for your product in a way that makes sense? What happens if the vendor goes bust? Will it scale with you?

Saying that quick decisions are needed if you're going to make any progress. Do some research, make a choice and stick with it.

For example, some decision that I've been thinking about lately:

• Auth providers. I have a free and paid tier to my service. If I have 2.5k active users sign up who are not paying, I'll be spending $57 a month just to Auth0.
• Database architecture. I started with DynamoDB because I thought it would be easier, but there is certain functionality which I've found won't scale to the functionality I need and learning it is a pain.

To address performance scaling: it is readily available these days through IaaS. It shouldn't really be a factor for most infrastructure/languages/frameworks, you can always optimise when it becomes a problem.

In terms of performance, solve the issues you can see now with your reasonably-expected level of use. So many times I've fallen into the trap of building for a much more massive scale, only to end up significantly redeveloping the feature later on anyway, rendering the premature optimisation work useless.

I've been working on a concept about ideas vs ideologies. Hear me out...

An ideology is a system of ideals.

An idea (especially as product) is subordinate to an ideology.

Some companies call this a mission but to me it's bigger than corporate philosophies. Idegologies are about how you believe the world should be. Whether it's your household or your nation.

Ideologies don't say I believe this, ideologies say everybody should believe this.

To me, this is a development from "what is your why?" And focuses the conversation on collective meaning.

This is important because if you want to "scale" you have to get people to transform from their current ideology to a new ideology (your ideology).

All your products have to be able to fall under your ideology.

We can critique a lot of things about Facebook but Zuckerberg has convinced the world about democracy and freedom of speech to the point we don't even acknowledge the downsides of democracy and freedom of speech. It's an ideology the world is running with or struggles to fight against.

The "Idea" was the product in the Harvard dormroom

The Ideaology the world eventually bought into (initially) was unfiltered expression of individuality as a human right. (just my opinion.

Less about the idea more about can your ideals of the world persuade the world that it's a better view than they currently hold. Anything you build that's in line with that is "scalable" in my opinion.

Maybe I said a whole lot of nothing. Sorry if I didn't answer your question at all. I hope something in there helps. Now I'm wishing I could just save this is drafts. Sorry again.

One of the best ways to find out is to #buildinpublic and iterate as you go.

100%. If you are not thinking about scalability in the early days, things can get messy further down the line.

Focus your "is it going to scale" energy into "how am I going to market this thing". This way you might reach a point where you will actually need to start thinking about how to scale it from engineering side.

I think about the groundwork to make life easier down the line. Don't get too hung up on it though, there will always be issues you don't think of down the line anyway!

Everybody says that you shouldn't worry too much about scale early, and with a good reason. But I have always had an issue with that :p I spent quite a bit of time to ensure that my product DynaBlogger is scalable from the start, and speedy. For example I host the platform on Kubernetes, which allows me to add nodes very quickly if traffic goes up. The reason I was kinda worried about this stuff is that with an app like mine it's not just about the traffic that comes from my own users when using the app. It's also about the traffic generated by visits to my users' sites, since it's a blogging platform. So for example if someone publishes a piece of content that becomes wildly popular and ends up to the front pages of some high traffic communities, then I need to be able to handle that. So if I think about this, I don't think all the time I have spent with optimisations upfront is entirely "wasted" even if I am at a super early stage.

What kind of scale are we talking about?

Code modularity, ie. thinking about extending it later? Then almost not at all.

Load, ie. not dos'ing your services with too many requests? A reasonable amount. I personally am not so good at SQL so sometimes I worry about terrible queries clogging up the db.

I think if you accept the reality that most startups won't make it all that far, it'd make it an easier choice to procrastinate scaling and optimization until you see significant traction.

I find Paul Graham's writing about this pretty insightful.

I'd say that you shouldn't think about scale early on. I've seen way too many over-engineered software products in the past. Things where a simple RoR app would've been way more sufficient.

Especially in the early days you want to validate your idea and move fast based on feedback. Don't fall into the trap of premature optimization. Get something out the door ASAP and worry about scale later on.

The only thing to keep in mind is to pick the right stack / technology for your problem at hand. Don't choose tech because it's trendy right now. I'm a believer in choosing "boring" technology because there are way more resources out there and there are less unknown unknowns.