This is a comment I wrote a little while back, you can see the full context here, but the premise of the conversation was about how companies like Google and Facebook have a totally different set of requirements when hiring programmers than startups or smaller companies.

[...] Companies like FB, Google, and Amazon need to test programmers on data structures because certain structures work better in certain situations, and when their software engineers know which tools to use to optimize a process to run in 5μs instead of 10μs... well, let’s just say for a company running tens or hundreds of thousands of servers, every microsecond saved means less servers the company needs running. And less servers = more $$$.

But for most startups or mid sized companies it’s way more important that developers know how to get shit up and running, and less important the actual code they write to get there.

The problem is a lot of smaller tech companies look up to companies like Google and try to copy they’re interview process because hey, it’s Google. And these companies never consider that just maybe an app with billions of users has a slightly different set of requirements than their app with 500 users.

Read that last sentence again:

And these companies never consider that just maybe an app with billions of users has a slightly different set of requirements than their app with 500 users.

I think this is super important in todays landscape. A lot of MVP teams, startups or mid-sized companies try to copy companies like Google or Facebook, which makes sense on the surface...

I want my app to be the ${topTenApp} of ${industry}, so why wouldn't I use the same tools and processes as them?

Here's the difference.

Google used that tool or process to solve a very specific technical problem they faced as they grew, versus the copycat company that didn't actually solve anything by using the tool, but actually created more problems.

Kubernetes is a powerful tool for scaling services, but you won't ever need to use it if you don't actually have any users to scale for.

Using it to develop an MVP just adds unneccessary complexity, slows down development time, and makes hiring suitable developers harder down the road. Just stick with the Heroku hobby dyno and change it when you actually need to.

This same rule applies to dozens of tools and patterns. Microservices. Machine learning. React native. CDNs. Jenkins. GraphQL. Blockchain. ElasticSearch. The list goes on and on.

I'm not saying you shouldn't use any of these in your initial build. If the whole premise of your app is to build a smart contract based ledger for real estate then of course you'll need to use blockchain, but if you're building a social media site for equestrians you probably don't need to use machine learning for suggesting content in the beginning.

When you're starting out, you should use a tool for one of two reasons:

1) It's absolutely essential for your MVP.
2) It increases productivity.

That's it.

Everything else can be changed, fixed or added later on.

Don't be a perfectionist and don't solve problems you don't have.

Just make something good enough that users actually want to use it, and worry about scaling when you need to.

If you do this the other way around, you might just waste months building a perfectly useless app.