Picking Your Tech Stack

If you really really want to, you can build a house out of sheet cake.

It's easier if you use something more sturdy though. It is easier to build your house with materials that your contractor is familiar with. For some houses that's wooden 2x4's and for some houses that's steel beams. The person that lives in the house won't notice the difference. But, it will make a big difference in the work for the contractor building the house.

You are a founder who is thinking through what tools to use to build your product. You are in a similar boat to the home builder. Given enough grit, you can build almost any product using almost any tech stack. But, this won't add any value for your end users. You need to make sure the choices you making are more like 2x4's than sheet cake.

Who is building your product?

The tools you use determine who will be building your product. This is the biggest impact this choice will have on your product's chances of success. If you are having someone else do the coding, choosing your tech stack is a recruiting decision.

Here you are striking a balance. You want a tool that the developers you will work with today can be effective in. In the future, you also need to pick a tool that will set you up to hire full teams of developers. Some languages like Go or Rust demand higher salaries than others like PHP or C#. Some markets have less developers with skills with certain tools. Ruby on Rails is popular on the east coast, but is less common if you are working with developers outside of the US.

When you are talking to a developer or an agency, they will suggest a language and framework to use. You need to confirm what they are suggesting makes sense. Talk to other founders of companies like yours. If you want to hire people who will come into an office with you, make sure they are in the same location as you. If you want a distributed team, look at companies in your same industry. Look at their job postings and talk to people in roles you'd like to hire someday. If you find that few or none of the companies you look at are using a certain tool, that can be a red flag.

What if I'm building my product?

So if you are a technical founder, the advice is a little different. If you are building your product yourself, use the tech stack that you are the most effective in. Your biggest risk is not getting a product out that people want to buy. The more you can do to get your product shipped and in front of users, the better.

If you pick a tool that is less common, you may need to expect to train new developers that join the team. This can be a big bonus for the teams culture. You will be in a great position to onboard the team as the developer who built the product.

Common traps

There are some common pitfalls to keep an eye out for as your making decisions on how your product should be built. These aren't situations to 100% avoid, but you'll want to go into them with your eyes open.

Having an outside agency build in a tool they don't know

Most agencies will not tell you that they cannot build using a language they don't know. They may feel confident that they can find someone with experience in your tech stack. Or they feel like can pick up experience in the language as they work on your project. This is almost always a bad idea.

If a developer is learning a new tool to build your MVP, it will always cost more than having them build your product in a tool they are used to. They also won't be aware of best practices for the tech stack, so will be starting your code base off on shaky footing.

If an agency wants to hire someone to work in a new language, they will be trying to find someone as fast as possible. They will have no pipeline and no experience evaluating candidates. Is this how you want to find the person to build your product?

If a developer doesn't have experience in a language, you need to change languages or change teams.

But is it webscale?

Your company might have more users than Google, someday. Chances are, if you are reading this, it won't tomorrow, and it won't 5 years from now. So, don't let your developers build your product the same way Google writes code. Using tools like Kubernetes or specialty cloud databases can solve a lot of problems. They are great when you have many teams of developers working on features for millions of users. They won't help you get features in front of users faster. They won't help your developers focus on providing value for your users.

Boring technical choices can scale to companies making many millions of dollars a year. Tools like Ruby on Rails, PHP, and C# have powered products with huge amounts of traffic. In the growth stage, you can afford to hire teams to rework parts of your application to handle the larger scale.

Make sure your team is making technical choices that will let them focus on product features.

At the end of the day for a startup, you want the team slightly bored by the technology choices. They should be very excited about the product features they are working on. This means choosing tools they have worked with before, and are common in the market.