When it comes to starting a startup, mainly building a product, especially if you have a technical background, the first thing you do is picking the tech stack.

If you have a tech background, then you want to leverage your valuable skills to build the product, hopefully after you validated the idea and that there is enough demand to justify building it.

IndieHackers.com has a dedicated group for Developers where all the talk is about tech stacks and which is the best tech for X for for Y, so it has to be a question a lot of people ask. And I’ll answer it.

Stick with a boring stack

Boring technologies are the best for a product that is just started. They became boring because they have been used again and again by a lot of companies. And all these companies would not have picked it again and again if it wasn’t doing something right.

Boring technologies are often the ones that offer the most stability product wise, because the languages and frameworks are mature enough to not dump weird unexplained bugs on you, for which exist open issues on Github created two months ago, staying there with no answers.

The quirks have been figured out long ago, and all is left is to build something useful using it.

Examples of such technologies that are considered boring, but they get the job done:

• PostgreSQL for the database (stay away from MongoDB, although a lot of inexperienced developers push it for all projects. You need a relational database as the core database, you’ll thank me later)
• Python with Django is considered boring enough (and some people steer away from it because its default philosophy involves templating and refreshing the page when you click something, but you can make more dynamic SPAs with Django too.
• CSS + SCSS/SASS + a frontend component framework: I see a lot of people going for Tailwind, which I consider to be a shiny tool that doesn’t do well, it just takes too much time to get the right combination of classes while also keeping your codebase sane. I prefer the good ol’ Bootstrap with a layer of SASS customization on top of it.
• Redis for caching, although in the MVP phase you won’t need it, and if you’re caching things you’re probably prematurely optimizing
• Containers for deployments. Some people will pick a VPS on which to host the service as a regular service, with a NGINX in front. That’s alright, but I prefer to use containers, as they offer a seamless development experience, and the nicer the development experience is, the faster you can ship.

Stick with what you already know

One other good criteria to choose your tech stack for an MVP is to just stick with what you already know.

If you choose something new, you’ll have to learn its quirks from scratch, learn all the new tooling a new language or framework comes with, and you’ll end up using it inefficiently anyway. At least less efficient than you would use the tools that you are already familiar with.

That’s why I stick with Python, React, Bootstrap and Kubernetes for deployment (thank God for managed Kubernetes, although I would definitely have picked another method to launch my containers).

Each developer that has a career definitely has a tech stack they made their money with so far. So that’s the obvious choice.

Of course, there’s the issue of being specialized in a development niche, and lacking the experience with the development areas that are needed to put out a complete functional product.

If you are specialized only in backend technologies, then you need to build the skillset for frontend development and infrastructure work. Same if you are specialized in frontend technologies: you need backend and infrastructure.

In that case, the best choice is of course to pick something boring (see the previous section).

What if I am not a developer?

Well, then it gets tricky. Building a product requires … well… building, and you have to be resourceful to be able to build something without having the tools of a builder.

From here, I see three options:

• try to put together an MVP using technologies available for people like you. I am talking about no-code tools, but they are somewhat limited in functionality. Alternatively, you need to find a way to deliver value and get paid without building a fully fledged product at all: a lot of non-technical founders start doing what they do as a manually performed service, and when they draw in enough money or interest, they seek funding to hire people to build it, or then partner up with a technical person.
• pay to build it: although to do it, you need capital, and it’s a risky endeavor if you don’t really know how the development process and deliverables look like. There are freelancers out there that oversell themselves, fail to deliver, or just outright scam. But the good part is that if you do this and find good freelancers to give life to your idea, then you already proved that you have “skin in the game” and will make you appear more serious when pitching this to possible cofounders or investors.
• partner up with a technical cofounder: although easier said than done, it’s probably the best way to go about it. But to do that, you can’t just go to them with an idea, because they gem bombarded by idea people wanting to access their skill set for cheap or for free. You need to prove to them that you are reliable, did the groundwork, prove interest and prove that you have skin in the game. Check out my other article about finding a technical cofounder.

Conclusion

In conclusion, picking the tech stack is a big choice that will shape how you deliver, more importantly: how fast you deliver and the quality of your work.

To reduce the risk, as a CTO of a tech startup, I advise you to pick something boring (which is battle tested, is mature enough and has a lot of resources available online in case you get stuck), or something familiar (the speed of delivery you gain by skipping a whole new learning curve is very valuable in the early days, when you just need to iterate fast and put the product in the hands of the customers fast). If you’re not technical, then you have multiple options to get a product going: either build it with no-code tools or by offering the value yourself in a more manual way, just to prove some traction and get some money in, pay for the development of the product if you have the funds and the managerial expertise or find a technical cofounder to join you.

Thanks for reading The Tech Bubble! Subscribe for free to receive new posts twice per week about indie hacking, tech and startups.