Akhil Gupta is an industry leader in the field of technology and product development with over 14+ years of experience. In his career, he has delivered innovative products for businesses of various scales and using multiple technologies. A particular area of expertise for him lies in building MVPs and growing them into full-blown products that are currently being used by millions of users across many domains. Currently, he is heading the technology function at Faballey (faballey.com) where he leads a team of highly skilled and motivated technology workers in building both consumer-facing and internal applications with a special focus on scalability and usability. He specializes in building large scale B2B and B2C multi-platform applications using cutting-edge technologies and architecture patterns like Microservices, Containerization, Docker, Kubernetes, NoSQL databases along with RDBMS.
When I started my career some 15 years back, the lives of people like me who wanted to build a product were much easier. Java and .Net were the prevalent leading technology choices for enterprises. PHP was just making its name with the advent of platforms like WordPress and Joomla. JavaScript was in its early stages of adoption. Languages like GO and Rust did not even exist. There were no smartphones so no need to worry about native apps. There was only one kind of database available – SQL. NoSQL was not a thing. If you wanted to build a product then, you just had a couple of technologies to choose from and on the basis of the talent available to you, you would make that choice. Sure, having more choices is nice, but having fewer choices does make your life easier.
The world of product development is entirely different today. The sheer number of choices an entrepreneur building his startup or a product manager building his internal product has just in terms of tech stacks is truly, for the lack of a better word, mind-boggling. All these options mean that I can pick up the best-suited tools for the task that I have in hand and no longer be limited by the simple lack of options that I faced back in the day. We are no longer constrained to limit ourselves with building the product that these limited options will allow us to build and truly build the product that we actually want to build. But all is not well just by the virtue of having all these options. Not only do we have a lot more options purely in the form of programming languages and database types, you have so many frameworks to choose from within that technology that decision paralysis has become a part of the product development process. Today more time is being spent on analysing, comparing, and finalizing the tech stack than is being spent on actual product development. The simple fear of “what if we choose the wrong tech stack” makes it very difficult for most of us to make a clear choice. I myself get stuck in the same cycle sometimes when I am evaluating a few options for a new product and reach a sort of stalemate where it becomes hard to select or reject any technology option simply on its own merits.
As someone who is regularly tasked with building new products, and who faces these challenges every time, I have built a framework that I use to help me decide. With this framework, anyone building a product – a small start-up or a large enterprise can make technology choice decisions quite easily.
Can it be built by the tech skills I already have? Unless you have some highly specific requirements for your product, which would have actually made your tech choices much easier, chances are that it can theoretically be built with the most common tech stacks. In that case, the quest becomes “finding the best tech stack” for the said problem. I do not run after this elusive “best” and first evaluate whether the product can be built using the tech stack I already have. By “already have” I mean technologies I already know or am already using. Further weightage is given if I have developers/technology people in my team already who know the said technology. Even though this might seem like a logical choice that need not be mentioned explicitly, somehow a lot of us get stuck in the chase of the “best technology”. Save this time that you would have invested in first figuring out a new best technology and then subsequently building a team around it and invest it in getting the product up faster.
Do not be distracted by new-age buzzword frameworks and tech stack posts that you read on Hacker News. The sooner you launch, the sooner you will get to start work on the next iteration of the product. For your customer, your technology choice is inconsequential as long as they get a high-quality, reliable, and product fast. And you will always launch fast with a technology you are already familiar with. Instead of trying to solve the problems you cannot even anticipate today it’s better to start with what you know and tackle the issues as and when they arrive. A product rewrite/rebuild is an entirely normal aspect of the lifecycle of a product so feel free to rebuild your product with a new “better” technology in the future when you actually know what kind of issues you need to consider. But today move with that’s familiar.
Now, what if the tech stack you already have is not suitable for the task or you don’t even have a tech stack in place (you are a startup maybe) how do you choose from some of the options you have come up with which you think are good for you? It’s actually very simple. You choose the stack which is the most accessible to you. By accessible I mean the stack for which building a competent team is the easiest and most convenient. If you are building your own team by hiring your own product developers it makes the most sense to use a technology for which finding talent does not become a problem in the future. You do not want to invest in any technology where the expansion of the team becomes an issue in the future just because of the small talent pool. This is precisely why technologies like Java and .Net are still at the top. Even if you are planning to outsource the product development work to an external provider, this factor should always be considered. Actually, it becomes even more pertinent if you are outsourcing the development work since eventually you will have to bring the product and the team in-house, and at times not finding the right people could result in your product really suffering. This also includes technology leadership of course.
As a last step of the framework, choose a technology for which you can find support easily. Choose slightly older, stable technologies which have a lot of resources available and a thriving community over something very new and coming. Sure, there are a lot of benefits of being an early adopter of an up-and-coming technology but that also comes with the risk of being stuck in an issue for which no support is available, at least for now. Products backed by larger organizations, like React, Angular are always a safe choice. This is especially important if you are using some open-source technology since no one is really contractually obligated to help you with your issues.
If you notice carefully the entire theme of this framework is around making the process of product development faster and robust. It is quite common for people building products to lose sight of the simple fact that their end-users, whoever they are, do not really care that much about the technologies used in the product. A typical Facebook user doesn’t care about how it works or if it uses the best possible technology. All they care about is that they have access to Facebook and it functions as it is supposed to. This is true for your product as well. Concentrate on building first, optimize the technology later.