Shuhaid Lambe
Shuhaid's Blog

Shuhaid's Blog

How to choose a tech stack for your product

Photo by Alexander Schimmeck on Unsplash

How to choose a tech stack for your product

Shuhaid Lambe's photo
Shuhaid Lambe
·Aug 4, 2022·

9 min read

Featured on Hashnode
Play this article

Table of contents

  • The problem of choice
  • Take your pick
  • Next up

Welcome to the series How to build a tech product. This is article #5 of 11 articles that touch upon various aspects to consider while building a tech product.

In the previous post, we looked at how to define the architecture of your tech product, in this article let us look at how to go about choosing a tech stack for your product.

The problem of choice

Barry Schwartz in his famous Ted talk - The paradox of choice, talks about how too much choice has lead to make us not freer but more paralyzed, not happier but more dissatisfied.

A similar feeling exists in tech, when it comes to choosing the right tools, language, framework, database, infrastructure, et al. You too, may have to confront some of these feelings when faced with making a choice:

  1. Paralysis i.e. fear of making a choice
  2. Feeling of regret about not choosing another option
  3. Managing your expectations

Overcoming doubt

Nothing is as exhausting as indecision. To overcome paralysis of indecision, simply set a deadline to make a decision and stick by it. Setting deadlines can be a great motivator to get things moving. Set aside time to do your homework, the time you need to set aside is defined by the size of your project. So if you are running a large project with a large budget the amount of time allocated to make your tech tooling decision should also be proportionately higher.

Your choice of tech stack will be based on all the work you have done so far i.e. preparations to build your tech product, documenting requirements, creating the architecture for your product.

Commit and move on

Tech is opinionated, one can always find better ways of doing something or a new tool, library or product which gives you something more. Once you have made your decision move on. Unless, you are stuck and you cannot find a solution with the tools you have chosen. In such cases where you need to replace a tool, make sure there is little or no impact on your timelines. If there is an impact, then analyse the cost benefit of changing. At times, it makes sense to use or stick with tools that might not be the perfect fit for the job. As the benefit of replacing it, does not justify the impact and cost. On the other hand there are times, when changing a tool is necessary to adapt to a business situation.

In one of my corporate stints, working for a bank, we were using a message broker to process messages. All ran fine for years, till one day large files started coming in from an upstream system that was changed. This message broker based system which was processing hundreds of messages per second was slowed down almost to a standstill. The message broker was not a good fit to handle large files, the ideal fix was to change the upstream system. But changing that would take a lot of time, money and the worst of all tens of meetings 😱. There were ETL experts in the team who suggested, we try Abinito to handle this as Abinito could handle large file processing much better than message broker. While this was not an ideal use of Abinito, the change was made and it solved the problem at hand restoring throughput.

Tech stacks you use can suddenly seem inadequate, that does not necessarily mean that you were wrong. It just so happened that the rules of the game changed. Now like any good player, you need to adapt around it.

Managing your own expectations

So you have made your decision and your product is ready. When evaluating your tech product, evaluate whether it serves the current needs of your business and its customers. Evaluate whether your product competes and wins (in most parameters) against your close competitors. Your expectations should be centered around core business impacting parameters and not against vanity parameters. Core business parameters which are relevant now and in the near term.

Remember, there is always some luck factor in decisions.

“Whatever you do, don't congratulate yourself too much, or berate yourself either. Your choices are half chance. So are everybody else's.”

― Mary Schmich, Wear Sunscreen: A Primer for Real Life

Take your pick

We all like to build things, there is great pleasure to be had in creating something out of nothing. After all, as a tech enthusiast what's cooler than a group of developers sitting in a garage and coding away over mugs of coffee. But, "Let's start building" should not be your first reaction. Especially if what you are building is a commercial endeavour, it would be prudent to a take step back, analyse your options before you start building.

Begin by breaking up your product in to multiple components and start choosing a tech stack for each of your components. Most products can be broken down in to multiple components. For a web / app product you can break it down in to the following high level components:

  1. Marketing website, landing pages, blog and other static pages
  2. Admin console for your internal usage
  3. Customer facing mobile application
  4. Customer facing web application and/or API layer

Build v/s buy

Across all your product components figure out if there are existing solutions that you can adopt (open source) or buy (commercial products). The components needed in building most projects would already be available in parts or as a whole. Do your research - if nothing, it will be a useful exercise to see how others have built their products.

For example, most products need a marketing website with a blog. Explore existing stable products like Wordpress, Ghost, etc. for this. It will make your life so much easier, if you do not need to go to your developers to update a typo or add a new copy section in your static pages. Stability and security concerns around CMS systems like Wordpress can be circumvented with APIs. Using APIs from your CMS gives you the best of both worlds, a simple to use admin console to update your site content or blog and the ability to create & publish static marketing web pages without depending on the CMS rendering layer and its database.

Similarly, if you need an admin console for managing operations & support look for existing admin console implementations which you can build upon. Adopting existing administration consoles can save you a lot of development time and effort. Explore options like Forest admin, Laravel Nova, etc.

On the UI front too, existing frameworks or libraries can be used to cut down development time. Explore options like MUI, Tailwind UI, etc.

If you are in an idea validation phase and need an MVP. Don't just look for components, look for existing SaaS / PaaS solutions that have created a fully baked product. A product that can get your MVP off the ground in quick time. For example - if you are looking to build a marketplace and need an MVP to test your idea, explore options like Sharetribe, Nautical, etc. Similarly, if you are looking to build an ecommerce store start with options like Shopify or Woocommerce. In your MVP phase, do not worry about some features these existing platforms might not provide out of the box. Use the off-the-self option to prove you have product-market fit. Picking this approach can help you save both time and money.

Code away 👩‍💻

By now, we are clear what parts can be procured / bought and what needs to be built. It's time to pick the tech stack to build your product. The recommendations made so far and going forwards have assumed the product will be consumed over the web & mobile.

Server side

Let's first address the backend. The most popular backend web development languages out there today are Javascript, Python, Java, C# and PHP. For medium to low throughput applications Python or PHP are safe choices. Its relatively easier to hire developers or vendors who have worked in these languages. For high to crazy levels of throughput look at Go. Once you have settled on a language for the backend, pick a web framework which has a good online support community for example - Laravel for PHP or Django for Python.

UI layer

Base language on the front end will be HTML + CSS & Javascript / Typescript. Here you will need to choose between Javascript frameworks like React.js, Vue.js or Next.js. The choice depends on the nature of your web application. For example, if you need server-side rendering and static web pages across your application Next.js is the better option. React.js or Vue.js are the better option to develop user interfaces for single page applications.

Your UI designs can help deduce if you can use existing HTML frameworks like Tailwind, Bootstrap, Material to help speed up development.

Mobile app

Clearly define the reasons you need a mobile app. Are you a mobile first business i.e. are your users going to be acquired primarily via the Play store or App store? Are your users primarily going to need the mobile experience just to view some aspects they would normally see via their desktop web browser? The answer to these questions can help identifying your mobile tech stack.

In the first case, where you are a mobile first business look at building your app with one code base for both Android and iOS. Here you can consider options like React Native & Flutter. For the second case, consider building a progressive web app (PWA) instead of a native app. PWAs allow the user to use and experience the app via their mobile browser. Your users can also install the app directly from the web, without going to the app store. Products that have adopted PWAs for their mobile web interface have seen significant increase in conversions and engagement. Here is an example of the Pintrest PWA case study that shows several improvements in their core business metrics after adopting a PWA.


The first choice to make here is, whether you need a SQL or NoSQL database. The answer again is, it depends on the nature of your application. If your applications data structure is not set and the parameters you need to store can change frequently then using a NoSQL database makes sense. Another indicator would be if you need to store a lot of BLOB/CLOB's in your RDBMS then consider a NoSQL database like MongoDB. On the SQL database front options like PostgreSQL, MariaDB are great open source options which are supported across all cloud providers.

Next up

The options available to build a web / mobile application are mind boggling. As a business owner / key stakeholder its easy to get lost in a sea of options. Take your time to choose from the available options. And lastly, make sure to consider if you will be able to find, hire and retain the tech talent as per the tech stack you choose.


Next up, lets learn how to estimate the time & costs involved in building your product.

Share this