Alvin Crespo

Use what you know.

Yes, that sounds boring - but it doesn’t matter. It’s good advice.

If you haven’t checked out Yevgeniy Brikman’s book “hello, startup” - you’re missing out. One of the best pieces of advice he gives us is that when we are picking a tech stack - we should use what we know.

how do you choose the initial tech stack for a startup? […] go with what you know.

— Yevgeniy Brikman, “hello, startup”

He then goes on to list several examples of successful startups that did just that:

• LinkedIn (Java)
• Github (Ruby)
• Twitter (Rails)
• Foursquare (PHP)
• Pinterest (Python)

Why did they do that? Well, because that’s what their founding teams knew.

I write this because it’s very easy for us to get trapped by the latest shiny thing. We have GraphQL, Apollo, AWS AppSync, Svelte, Tailwind CSS and so many more. This is all good, each technology is solving real-world problems. But, are they your problems? Do you really need to learn all these new technologies?

The truth is … no.

Should you be familiar with them? Absolutely.

It can be fun to learn a new technology that promises all sorts of theoretical benefits, but your goal in the early days of a startup is to learn what your users want, and anything that takes time away from that is a waste.

— Yevgeniy Brikman, “hello, startup”

:point_up: is how I live my life as an engineer these days. I use technology as a way to solve the user’s problems.

So, when should you consider new tech?

The trick is not the initial choice of technology. The initial decision is guaran-fucking-teed to be wrong… eventually. The only question is how long it’s going to take to be wrong. The trick is recognizing when you hit that inflection point where you need to have the courage to just kill the thing rather than apply Band-Aid after Band-Aid after Band-Aid to it to keep it alive.

[Scott 2014]Kein Scott, SVP at LinkedIn, VP at AdMob, Director at Google, “hello, startup” 2015

It all starts with an understanding that what you’re currently building will not meet the needs later down the line. Either it’ll crash and burn at scale (Twitter/Rails) or the needs on your project will change as the company pivots.

Over the course of my 10+ year career, I can say I’ve never built a system that has stayed the same for more than 3 months. There are many reasons for that, but one thing is certain - software evolves over time.

Thanks to Yevgeniy Brikman for sharing his experience in such a way that has helped bring calmness to the way I build software today.