Often when starting new product development, our technical teams must make a decision: which tech stack should we use? In this case, “tech stack” is a bit of a catch-all term. It might include programming language, developer tooling, hosting environment, framework(s) selection, process tooling, and other concerns. The amount of choice can sometimes feel overwhelming on a purely greenfield project. Below, I’ll lay out a simple approach to tech stack selection I’ve used in the past that has helped me make pragmatic decisions.
Getting started: How green is the field?
Start by identifying the significant constraints on the decision. For most projects, the most significant constraints aren’t technical but rather are business- or people-related. For example, say we’re building a new web application for a client that has a significant investment in Microsoft technology and a team of .NET developers who will eventually take over the codebase long term. In this situation, there would have to be a very good reason to choose something other than .NET for the backend.
Another example: startups may prefer a language or technology because they believe it will make their technology a more attractive acquisition target. I’ve worked with multiple startups that preferred native mobile application development (e.g., Kotlin on Android, Swift on iOS) over cross-platform frameworks like React Native for this reason. The cross-platform framework may have saved time on the initial build. However, it was discarded as an option for strategic business reasons.
Once you determine the most significant constraints, you’ll have narrowed your potential solution set down to fewer options.
Identify what’s important.
The next step is defining how you will evaluate the choices still on the table. Ideally, you can list 10-20 characteristics that you want to see in the tech stack. The mindset you should have is “my ideal tech stack would…”:
- Have strong dev community and open source support.
- Be cloud native.
- Allow our software to scale over time as our user base grows.
- Enable us to attract and hire top developer talent.
- Have good developer ergonomics and tooling.
- Be high performance for computationally-intensive tasks.
- Meet security standards.
- Align with our existing team’s skills.
- etc.
Sometimes, there will be a significant difference of opinion among the technical team going into tech stack decisions. In my experience, developers like to pick languages, frameworks, etc. they are most familiar with. Familiarity is definitely a positive but shouldn’t necessarily be the most important criteria for evaluation. In this situation, I recommend teams use a collaborative exercise to define the list. Personally, I have used the Hopes and Fears Innovation Game as follows:
- Start with fears. Ask everyone to write down on Post-it notes the pain points they’ve experienced in past systems related to tech stack choice that they would like to avoid in the new product.
- Group common fear themes together.
- Move on to hopes. Ask everyone to list characteristics they would like to see in the new system. Review what people wrote, ask them to expand on their points, and group common characteristics together.
- The common themes that are uncovered in “Hopes” are the characteristics you’ll use to evaluate the tech stack choices.
The above approach works well when there is a difference of opinion. It lets folks feel their voice was heard and drives alignment around how we’ll make the decision.
Score the contestants and make a choice.
I have found that listing these characteristics out in order of importance is helpful. Once you have the list, you can organize them as rows in a spreadsheet. The columns contain the tech stack choices you’re considering (e.g., columns may have frameworks like Express and Next.js, or languages, cloud platforms, etc). From there, the work will be to score the options based on your current team’s knowledge or via research. Some criteria will be subjective, and that’s okay. One source I’ve found useful for gauging industry attitudes toward a specific technology is the Stack Overflow Developer Survey. Scoring can be a collaborative process where the team discusses/argues.
After scoring the options, it’s time to make selections. Because everyone had a say in the creation of the scoring criteria and were involved in the scoring itself, it should be easier for folks to disagree and commit. The above approach is general and could be used for any decision, not just tech stack). I’d love to hear from the community about other tactics and approaches to tech stack choice that have worked.