Which technology or which technology stack to choose for the new product that you are building. Is there an ultimate tool, a silver bullet to solve the problem that you are facing? These are important considerations for any organization, especially so if you are a product start-up with cost and time forever against you. In any enterprise space the considerations are ordered, there are a set of tools that you can use (mostly based on the skill set of the people around you). Choosing a new technology in these cases means a lot of technology comparisons and conversations convincing its use. What usually works in bigger organizations are their policies and mostly the convincing capability of the sponsor driving the change.
For a start-up, however the considerations can be a lot different. With the prime directive being getting a beta version out to validate your idea and drive revenues, what you can consider is both limitless and limiting at the same time. Here are a few considerations which were used while driving the products at a tech incubator I was involved with earlier and right now at AutomataPi.
(i) Does it solve the problem? A technology stack at the end of the day is a tool and not an end product. Any technology that is chosen must necessarily solve the business problem. While this is an obvious statement it is necessary to consider in depth the goals of the business. Can the tool set efficiently solve the problem at hand, for e.g. using a big data toolset while the data flow size of the product is predictable may be an overkill and may unnecessarily bloat your product. In case your application is a set of microservices which communicate over REST services, does using a container such as ‘Apache ServiceMix’ or ‘Mule ESB’ make sense. Also, does it meet the expectations of your target user base? If your target user base is used to dashboards with the finesse that say a ‘Tableau’ provides then your UI/UX tools needs the same technical capabilities.
(ii) Does it scale well? This is a consideration in terms of both the team as well as the tech. Will the same tech stack work when the company grows? If now implementing the stack requires a team of 5 people, with going live would the number of people grow exponentially to maintain it. Also in terms of the technology itself, whether scaling the same can occur seamlessly.
With the cloud tools available today, setting up horizontal scaling is remarkably easy. However, the resources utilized when you scale can be considerable. Does your application work better as a monolith, microservices or function as a service (FAAS)? An insurance application with an initial sizing can work better as a monolith, splitting it out could unnecessarily complicate deployment, while a set of APIs that you provide may work better as FAAS or a consumer application would scale better as a microservice.
(iii) Is talent for the technology easily available? When you do need to grow your team are there resources available that you can hire quickly, hiring JAVA resources in Mumbai is easy, while getting experienced ruby resources may take a while. The language itself may not be that relevant as you could write a single threaded ruby MRI code to work very efficiently while you could write an inefficient multi-threaded java application.
(iv) Are there too many unknows in the equation? The speed at which your team can pick up technology matters. For e.g. understanding and using the new ‘Angular’ model may take a while and at the same time if the backend services or functions that you are building also requires a fair amount of research you know you will need to be a little patient for your product to shape up.
(v) Is there support available for the tool that you are using? There are open source tools that will go along great with the application that you are building, a set of libraries that help you get started on your problem with minimal lead time. There are also an equivalent number of open source libraries that are abandoned or not under active development as well. In case of bugs that may arise in the software you may be left to deal with them on your own. Also with advances in your underlying languages, databases etc, the newer version of these tools also need to be upgraded to provide support. This may stop you from utilizing the benefits of an upgrade which otherwise would be available.
(vi) Do you believe in the technology that you are using? Lastly it helps if the technology that you are using drives you, if you believe that the technology even if its new and unproven can solve the problems that your business has. It assists in selection of the technology as well as getting involved in the technology to iron out any chinks that exists. If it is innovation that you are driving getting a perfect honed tool to solve your problem may not be present. You are more likely to shape the technology to your need and persist with its use if the technology excites you.
There are a few other considerations on choosing a tech stack, viz portability of the technologies, if you need to swap out a component for another, the ecosystem around the technologies and its level of adoption. However, as with everything that is interesting in technology the answer always starts with ‘it depends’. Choosing a stack depends on the problem that you are trying to solve, your and your team’s expertise and approach towards creating the product. The main considerations for a new organization are always cost and time. Being a start-up the agility to prototype quickly and work out your technology stack is one of the biggest benefits. It gives you the ability to test out each component of your architecture giving you a quick visibility of what works well. Along with prototyping, dogfooding your products if possible can also be a quick way of validating your tech stack. For e.g. an identity service which you may build can be used to authenticate your internal applications. The focus that dogfooding can give you when you are the customer can help not only in validating but can translate your stack quicker into a useful product.
