One of the best anecdote on consulting comes from Professor Clayton Christensen. Andy Grove, Intel chief, asked the professor what his theory of disruption means for Intel. Instead of giving a direct answer, the professor taught Andy Grove, "how to think" about the problem. I have followed this method for decision making. Instead of seeking answers, I seek "how to think" about a particular problem. Such method has helped me make decision in varying situations. In the similar vein, let me give three guidelines to design tech-stacks for startups.
Pick the right tool for the job
When a fly invaded his meeting, President Obama rolled up a magazine and whacked the fly. He didn't ask for a gun or call up his army generals, or punch-in nuclear codes. He picked a near-by magazine, rolled it, and whacked it himself.
I'm often asked if .Net is better or Python is better or node.js is better for building a startup product. If there is a technology co-founder, my advise is always to start with the stack that they know. Later as the product grows, add what is needed, or move to a more suitable stack. Marco Arment coded backend for his popular overcast podcast player in PHP because that is what he knew. Later when it grew he switched to Golang. Likewise, Twitter was originally written in Ruby and then switched to Scala.
As it should be clear now, the right stack changes as the startup goes through its growth stages.
Build for iteration and feedback
Startup is all about validating ideas quickly. So choose a tech-stack that gives you this advantage. Validating ideas quickly is not only about tech-stack. It is also about company's devops process. It is also about having probes in the application to give you operational insights. This combination of tech-stack, devops, and application analytics help validating ideas quickly.
Most technology teams in startups don't invest in devops and application analytics. Lack of devops and analytics limits their agility and speed, more than the tech-stack.
Decide well or fast
Every business executive has to take ton of decisions. Lack of data complicates the decision making. I use a rule-of-thumb to help me decide. I ask myself, is this something money can solve at a later time? There are few problems that money can't solve.
Company culture is one problem that more money can't solve. In fact, money amplifies what is already there. So if a company starts with a sexist, dishonest, authoritarian culture, more money later won't turn the culture around later. Uber is an example.
However, lot of problems can be solved by bringing more money. Logo, website design, and tech-stack are some of the problems that money can solve. As I said earlier, Twitter switched from Ruby to Scala. Dropbox is experimenting with Golang. Facebook invested in writing its own compiler for PHP.
If more money can solve a problem, choose to iterate fast. You shouldn't wait on more data. Decide by your gut feel and most probably it will work out ok. If not, bring in more money to solve that problem.
If more money won't solve a problem, think deep. If needed, get outside help. Talk to people who have already solved the problem. These decisions will have lasting impact on the company. Getting them wrong will be a disaster for the founders and the company.
You can read the full article on my blog
Top comments (4)
This is exactly right. dev.to is a Ruby on Rails app mostly because that's what I knew and liked best at the time. It's still a Rails app, and that's not changing any time soon, but as we face new challenges, bring new people onto the team, and generally deal with the oncoming future, new tech choices start to present themselves. It wasn't out of total ignorance to what else was out there. I know some other languages and I had been working in Node more before starting this project, but Rails still was what I knew and liked and I didn't overthink it.
I'm very glad we didn't try to predict that oncoming future ahead of time.
Have to agree. I learnt sails.js quite in depth as an MVC node architecture. Whilst I can build using plain express or even some pure front end with Vue and nuxt.js I still fall back to sails when I want to get on with something fast. There's languages and frameworks I flirt with and then there's the one or two I feel married to!
Yes, same experience here. Important to add to the DevOps part, as far as I am concerned: Be critical when it comes to "hype" technologies and never forget that your code, at some point, also needs to run on some production infrastructure. Starting with the stack you know definitely is a good advice but you also should make sure you have an inexpensive and stable solution how to keep your code running on production-level (availability, stability, performance, backups, ...) without having to handle all this on your own. These days you most likely will be looking at public cloud hosting at amazon, google or Microsoft Azure - which might have an impact on which stack you choose.
I'm always reminded of someone's response to the "Ruby won't scale to Twitter" complaint:
Nowadays, I'd probably add "whatever it is, blockchain isn't the solution" :P