The very first concern which often gets too little attention is exactly what a tech stack is. In simple terms, it’s the collection of technologies and tools – everything encompassing a project’s code – which is used to build a website or a web app. LAMP (Linux, Apache, PHP etc) is one famous example of a tech stack. Today we see modern stacks that are far more complex.
Just like any building needs the right materials to stand, any great software initiative needs the right tech stack to succeed. The right choice can mean the difference between an adaptable successful product and an expensive false start, and the complexity of today’s tech stacks is an added threat for any decision. It’s common to find startups implementing enterprise tech stacks that were simply overkill for their stage of progression, leading to a high burn rate with little runway, or enterprises chasing the latest tech trends and ending up with an unmanageable tangle of incompatible technologies. With serverless, microservices, and an ever-growing list of programming languages and frameworks, it’s a daunting task to pick the right stack.
Importance of selecting the right tech stack
Choosing a tech stack seems to be an inconsequential decision. However, it has the potential to cripple or elevate your organization. It is akin to laying the foundations of a skyscraper using limestone or sandstone. Although both are functional, one is likely to last longer and support more stories. Similarly, the right tech stack may cost more initially, but will be able to support more traffic and a larger user base. As a tech stack underpins and supports a company, changing it later on is a difficult and costly endeavor. This is particularly problematic if there are many interdependencies between systems, or if the company is using an outdated language or framework. If it is likely that a startup will seek venture capital funding, it is important to use a tech stack that is scalable. Investors prefer to see their money being spent on growing the company, rather than on frequent rebuilding of the system. Choosing the wrong tech stack can also make it difficult to attract quality developers, as no one wants to work with outdated technology.
What are the differences between tech stack for startups and enterprises?
For startups and enterprise companies, the primary difference in their tech stack is the approach they take. Your product goal is to create a stable product that will stabilize growth. In comparison, the startup is focusing on proving the product to the market and may change directions at any time based on user feedback. Because the goals are different, this will affect the tech stack in a variety of ways and is important to understand the implications. Enterprise companies want to use mature, well-documented, and supported technologies. This is because the cost of any failure is higher and needs to be mitigated. Startups may be more willing to take risks on newer technologies to solve problems with the understanding it may incur technical debt to change it later down the road. The concern from startups is that if they fail to gain enough traction, they may need to pivot and if the tech product is built on enterprise-level tech with a lot of sunk cost, it may be difficult to justify doing so.
Factors to Consider
There are two broad categories for considering tech stack. One of them is the project itself and the particular knowledge used in existence of project; the other is ongoing development concerns. In the first category, while one would want to simply choose the best available programming language, this is probably too risky or onerous a strategy for most. Equipment is needed to program in a language or use a language-specific hosting service will be lost if the language falls out of favor. If the project is an open-source tool with a life expectancy equal to that of the language itself, or a project to increase the language itself, then this is not a consideration. Language choice is more likely to be guided by existing expertise; if a company is paying developers to learn Python, it is unlikely that they will want a new project to be developed using OCaml. In this case, it would be a decision between the best available language at the time and the best available language that the team already knows. For the former, it is a good idea to keep an eye on new languages and development in the form of prototypes. It may become clear that there is a fork in the road where it would be favorable to start again using the new language, and if this happens, it is better to do so sooner rather than later. At some point, a language will reach the end of its effective life, at which time it becomes infeasible to continue using it. Usually, it will be obvious that this is the case and a decision can be made to abandon the language, but a notable example of a language dying without anyone really noticing is pre-ECMAScript JScript. This currently leaves the most successful language in history (JavaScript) with no clear upgrade path. Finally, a language may not be used due to a strong belief that better alternatives will become available in the near future. In this case, the best strategy may be to outsource unskilled development with the old technology while keeping skilled workers ready to migrate to the new technology at short notice.
Scalability and performance requirements
When deciding what the best software solution for a business is, a critical factor is the projected growth path of the company. A small business will likely require similar software, but less complex, to that of a large business. For a start-up business, selecting a software stack which has the potential to scale to the desired end point is a cost effective solution compared to redeveloping the software on a different stack at a later date. This contrasts with a situation where a business is downscaling, as it doesn’t make sense to employ a highly skilled software developer to redevelop the software on a different stack when it’s already capable of doing what’s required. For both situations, the ability to execute the task is what’s most important. If the software doesn’t live up to expectations in a downscaling situation, it’s unlikely an attempt will be made to do it again. In an upscaling situation, failed attempts will eventually lead to the same result albeit at greater cost. Failure can often be traced back to the technology used and limitations with the scalability of the software. Considering the implications of future success or failure, it is clear that scalability is important. This leads to performance requirements—faster software is obviously preferable, but the required performance is that which meets the task at hand. If a task requires intensive computation and the software is unable to provide a reasonable response time, the value of the software is low. It is important to note here that many developers and small businesses fall into the trap of prematurely optimizing a piece of software to be fast, when in fact a faster solution isn’t required to meet the immediate needs.
Integration capabilities with existing systems
For a small company with no existing systems, it is often best to start from scratch with new technologies and leverage the experience of the development team. For a large company, it is quite different; it may already have a significant investment in certain technologies, and the new software may have to work with those technologies. An enterprise must consider the long-term cost of changing those existing systems to work with the new software, as well as the opportunity cost of not leveraging the capabilities of the current technology. In the healthcare industry, these factors often lead to the decision to keep using outdated technology, and certain industries and government organizations have many legacy systems. The decision on whether to build a new system, change an existing system, or leverage the capabilities of an existing system can have a significant impact on the choice of technologies for the new software.
The software you will be developing does not exist in a vacuum; it will have to work with data from an existing system. As a startup, you may choose to implement a complete package including a database and other back-end systems, or you may be looking to build a website that interacts with an existing data system. Enterprises almost always have existing systems. It is important to assess the impact of the new software on the existing systems and to understand how much effort will be required to make the new software work with those existing systems.
Development team expertise and availability
The expertise and availability of the development team is a significant factor in selecting the tech stack. The tech stack used should reflect the level of expertise of the development team, as using complex technologies which the development team has little experience of using may result in longer development time and poor maintenance quality. The availability of specific technologies may also affect the choice of tech stack, as some technologies have licensing models which may be unsuitable for a specific project or take a long time to negotiate. Open source projects are more flexible in this regard. Availability may also refer to the time constraints of the project sometimes. If a project has a very short time frame, some technologies may not be suitable as they require long set up times and specific environments. On a related note, the rate at which the specific technology is being updated should be considered, as certain technologies require constant monitoring and periodic updating in order to avoid degradation in performance and security.
Types of Tech Stacks
To an onlooker, all tech stacks could look the same but this is definitely not true. In essence, every web application has both client and server sides but the length at which they go to develop each side varies. Your basic stack is generally split into 2 categories, full-stack and specialized.
A full-stack is where the developers will have experience working in everything from front-end to back-end. They will typically have used a wide range of languages and technologies, often choosing the best one to use on a per case basis. Full-stack is usually used by startups on a small budget and time limit as they will have developers who can fill multiple roles.
A specialized stack will generally involve a greater focus on one side as the team will have developers who are mostly proficient in either front or back-end. The disadvantage of using this type of stack with a small team is having to only rely on 1 or 2 developers to handle the workload of an entire side of the application. The advantage of an established enterprise using this stack is to leverage experts in either front or back-end development to produce high quality software.
Full-stack vs. specialized tech stack
Let’s take more precise look at these two types.
Full-stack tech stacks are those in which the tools and technologies utilized for a certain function are consistent across the entire web application. An example would be using Node.js for both the back-end server and for routing/allowing the use of AJAX on the front-end.
Specialized tech stacks are those in which different tools and technologies are utilized for the separate functions of the application. An example would be using PHP for the server and creating a separate Ruby on Rails app for the AJAX-intensive portion of the web application.
Usually, there is a front-end portion of the application that the users will directly interact with, and a back-end portion in which the server is providing an API for the front-end to consume data. It is often the case with specialized stacks that different tools will be utilized on the front-end and the back-end.
Full-stack tech stacks are a better option for smaller startups with limited technical resources. Due to the fact that there is less to learn, full-stack developers can be more versatile and efficient. It also allows for rapid development and deployment, since there are fewer technologies and tools to manage. On the downside, full-stack web development is rarely the best option for the implementation of certain application functions. It also runs the risk of being “jack of all trades, master of none”, with the resulting application lacking in specific areas compared to if some of the portions were completed by developers with more specialized skills.
Popular tech stacks for startups
MEAN stack is a full JavaScript technology stack that simplifies and accelerates web application development. MEAN is an acronym for MongoDB, Express, Angular, and Node. Step by step, you will learn the individual technologies that make up the stack and how to use them together. All of these use JavaScript, which is great for rapid development and is also being seen as the future for web development. Node.js is a popular technology for its ability to handle concurrent requests. Angular is a powerful front-end framework maintained by Google, and Express is a popular back-end framework. With all of the changes in web technology, MEAN is looking to be the future for web development. As it only uses one language throughout and its scalability, this is a very cost-effective stack and a great choice for a startup.
Ruby on Rails is an open-source web application framework written in the Ruby language. It is typically used with a LAMP Stack, but there are other alternative stacks that use different operating systems and databases. Ruby on Rails has gained popularity among web developers in recent years with the introduction of a new era of web development and is often the first choice for startups due to the rapid development and lower cost of implementation. This is the technology stack that we use here at Liquid Light.
LAMP Stack is made up using Linux as the operating system, Apache as the web server, MySQL as the database system, and PHP as the server-side script. This is widely used among the open-source community and is best for building dynamic websites and web applications. As it is with open-source software, there are plenty of resources and components available at no expense. This is an advantage to small startups as license fees for software can be very costly.
LAMP Stack Ruby on Rails Stack MEAN Stack
There are three tech stacks that are popular among startups and variety in programming languages, databases, web servers, and software.
Recommended tech stacks for enterprises
One common flavor of enterprise is the data-centric company. Such businesses typically revolve around manipulation of certain data and often have existed for a long time before automation of their tasks. For these reasons, they will usually already have a clear idea of the tools required to solve their problem. For example, a company dealing with geographical data might have a need for a Geographical Information System. In general, these businesses will have their own specific needs and requirements, and off-the-shelf software will not be suitable. The technology for such businesses will need to encompass many diverse requirements and must be very flexible. It is usually best to stick with mainstream technologies and proven solutions unless the problem domain is very specific. An example of a very general technology with a wide area of application is Java. StepStone uses a stack based around Java technologies to provide a variety of custom solutions for internal and external customers.
Considering their complexity and varying demands, different flavors of enterprise have different requirements. In general, tech stacks for enterprises should be tried, tested, and reliable. New or unproven technologies represent too high a risk, as if they fail, the cost in both time and money is far greater than for a small business. Enterprises will also have far greater requirements for scalability, as many applications are essential to the business and as the business grows, so will the technology. Large user loads are common, so performance is a huge consideration; any technology that is unable to make efficient use of hardware will be unsuitable. Enterprises are also more likely to have dedicated operational staff, making automation of system tasks a high priority.
Pros and cons of each type of tech stack
For a new startup, productivity and speed are key. A full-stack framework can be a great way to quickly validate a business idea and begin to develop it further. With less concepts to learn and a more continuous workflow, a new startup can be more agile and build an MVP more quickly. Lowering the technical barrier to entry can also be inviting for entrepreneurs who may not be strong developers. While full-stack applications may not be appropriate for more complex or processor-intensive applications, they are a great choice for simple and CRUD applications, or ones that require a lot of real-time interactivity.
The biggest advantage of building a full-stack application is in terms of pure time and effort. It can take a lot of work to make environments, frameworks, and disparate languages all work correctly together. Context-switching between server language and database queries on the backend and AJAX on the frontend can be cumbersome. Projects can also be divided between developers on the frontend and the backend, complicating the coordination. With a one-language full-stack approach, the same developers can work on both the frontend and the backend. This can radically improve productivity. Furthermore, the mental gymnastics of translating between different languages can be outright confusing.
Decision-making Process
The decision-making process is an important one and needs careful thought and consideration in order to make the correct decision. As an example, a wrong decision made in the development platform could prove costly later on. So before making the decision of what platform to use, one must first understand the requirements and goals of the project. The decision-making team must evaluate and write down exactly what it is they aim to achieve with the project. From this, they can then create a list of objectives that the project must meet in order to accomplish the goals. Once these requirements and goals are defined, one can move onto the next stage.
After the requirements and goals have been set, the next stage is to evaluate the different tech stack options that are available. During this stage, it is important not to get bogged down with technical details. It is often a good idea to create a comparison table in order to compare the pros and cons of each option. This will give a quick and easy comparison and make the decision easier. During this stage, it is important to keep an open mind about the different options. It may be that a particular option being considered does not meet the pre-defined requirements and goals. In this case, the only option is to discard that stack and move onto the next one.
Defining project requirements and goals
One technique which we’ve found useful is to conduct a SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats). This is a strategic planning tool used to help a project understand what it has going for it and areas where it could improve, or things that could hinder it in the future. These consider the internal and positive factors, whereas threats and outside factors can influence the project negatively. This will give an organizational view of what you’re trying to achieve and then can be broken down into definite goals and what you’d like the project to achieve in each of the 4 categories.
Your project requirements and goals will vary depending on what your company and the development team are seeking to achieve. Ask yourself what the most important thing is that you are trying to achieve. Is it to establish a more efficient framework for development in the future? Are you trying to scale your current application and need a system that can handle the increased workload? Maybe you are interested in streamlining the process for deploying your application. These are all potential project requirements and goals that can influence your decision when choosing a tech stack. Create a list of high-level objectives and goals to achieve, showing what success looks like for you. This will help clarify the focus of the project and what the desired outcome is.
Once you have a good understanding of what a tech stack is and you’ve made the decision to move forward in an effort to integrate a new one into your current system, you will want to define the project requirements and what your goal is for doing so. Assessing what your needs are and setting up a roadmap to reach the end result are crucial in the decision-making process for choosing a tech stack.
Evaluating different tech stack options
To understand what is available, it can be beneficial to consult a systems integrator, or a software development company that has experience with a wide range of technologies. By having a consultation with them, you can leverage their experience and avoid any obscure technologies that are outdated or have a small community. It is also possible to perform this research in-house, but it will take longer and is likely to be less accurate, unless you have employees with previous experience in a wide range of technologies. By taking a look at the current job market, it is also possible to get an indication of what is popular and where salaries are high – this can be a good factor of the popularity of a technology.
To evaluate the different tech stack options, the first step is to understand what is available. This requires having a good understanding of your project, the requirements, and what is important to it. For example, a startup may be considering a LAMP stack because it is cheap, while an enterprise company may be considering a .NET stack to leverage Microsoft technologies. The startup may be unaware of the free .NET alternatives, and the enterprise company may have dismissed LAMP without considering it in depth.
Conducting proof of concept and prototyping
A prototype, on the other hand, is a simulation or model of a final system and shows how the final system will look and feel. It can be an initial build of the final production and developed in parallel with earlier phases of a solution. A prototype has various uses, especially when used as a usability tool, providing proof of solutions to requirements that require a change to the way they are presently fulfilled, and for training for end users who require knowledge of how to use a system post-implementation.
A successful prototype, based on, for example, a UI design, could eliminate rework at the end of the development and ensure that user feedback is positive. Proof of solutions to changes in business processes can be provided by a prototype of the change in the system in question and a save/return scenario to present the effect of changing the process. Any changes in the data would require an early model of the new data structure and possibly a new load of a subset of the data.
A proof of concept (POC) is generally a prelude to a more general solution. The importance of conducting a POC is to validate the technical and functional design, as well as the build and deployment process of a solution. The main success criteria of the POC would be to prove the solution design and also to demonstrate the ease with which the solution can be built and deployed. A POC would tend to be a series of exercises that are not part of the mainstream build and deploy.
If the POC is a success, the build can usually be transitioned straight into development, and an agreed solution design means that there are no “back to the drawing board” scenarios. A failure in the POC is not necessarily critical, providing tangible reasons can be provided, which may result in a revised design and POC.
However, an unclear reason for the failure would suggest a gap in the requirement or the solution design, and failure to identify and fill that gap could have serious implications on the project at a later stage. With regards to a data warehousing project, it may be decided that a certain portion of the data should be loaded into the warehouse in a certain way.
Making the final decision and implementation
We have reached the final phase of the decision-making process. The deciding factor in choosing the right tech stack for your project may be determined by the availability or allocation of resources, time constraints, scalability, and the importance of simplicity in solving complexity. Prioritize the requirements and constraints set out in the previous steps and rank their levels of importance.
Now is the time to replan the project at a higher level. Consider the tools and options available within the selected tech stack and how each one will be employed to fulfill the requirements. A weighted decision matrix is a tool that evaluates options against a specific set of requirements. It is useful for comparing alternatives when there are many factors to consider and limited resources to work with. This matrix provides a clear decision and explanation based on defined metrics. This is also the point where you will want to make contact with third-party vendors, attend user groups and network with other developers who have had experience with the tools you are evaluating.
