Building a dev team on a single tech stack isn't good

Why building a team/architecture on one tech stack vs. many is a bad idea

Original article appearing on Medium

I’ve heard it not only from Private Equity but also inexperienced development leads.

“We need everything on one architectural tech stack, it’s just easier to manage.”

Mind you that there is a big push, especially around enterprise technology and software, that everyone and their cousin is using Azure.

Through our research for a specific application, we found that Azure was missing a very important feature and suggested Google Cloud or AWS instead. The client responded with the above comment (as well as a PE firm) and I’ve questioned why they think this ‘easier’ path is better.

It is possible to design application software with more flexibility and scalability by relying on different architectural tech stacks. When you use different stacks of technologies, you can take advantage of the best parts of each technology, which has its own strengths and weaknesses. Using multiple tech stacks can also make your program more durable by letting you use different stacks for different parts or parts of your application and by letting you switch to a new stack if one becomes out of date or no longer supported.

A software architecture development team can get several benefits from building an app on more than one tech stack:

  1. Flexibility: Using multiple tech stacks allows the team to choose the best tool for the job, rather than being limited to the capabilities of a single stack. This can lead to a more efficient and effective development process. It is also important to note that, while Azure is a powerful platform with many useful tools, it may not be the best choice for every application or every aspect of an application. Using multiple tech stacks can help ensure that the team is using the best tools for the job, rather than being limited by a single platform.
  2. Scalability: Different tech stacks have different scalability characteristics. By using multiple stacks, the team can ensure that the application can scale effectively as needed.
  3. Resilience: By using multiple tech stacks, the team can create a more resilient application. If one stack becomes outdated or unsupported, the team can switch to a different stack without having to completely rewrite the application. Using a single technology stack, like Azure, can make development easier, but it can also limit your options and make it harder to adapt to new needs or technologies. Also, if there is a problem with the Azure platform, the whole app could be affected.
  4. Mitigating vendor lock-in: Using multiple tech stacks can help mitigate vendor lock-in, allowing the team to more easily switch to different vendors or technologies if necessary.
  5. Innovation: Using multiple tech stacks allows the development team to explore new technologies, which can lead to innovation and new ways of solving problems.

It’s important to note that building an app on multiple tech stacks can be harder and require more resources, but the benefits can outweigh the costs in the long run, making it easier for the app to adapt to new technologies and needs.

So before making a decision on what seems to be the easiest or most logical choice when deciding on architecture and your development team’s tech stack expertise, really consider the long-term implications of this decision and why placing all of your eggs in one ‘tech basket’ probably isn’t the best idea for your success.


Connect with me @Makoto Kern — IIIMPACT, Inc.

We’ve launched hundreds of digital products by partnering with our clients both strategically and tactically through DesignOps and DevOps best practices. Visit our website to learn more and see more news and articles on these topics.