How do you pick the right technology?

These are the questions and considerations I use to pick a tech stack for that fits my client and my project.

I’m a developer. I have frameworks I like to use and opinions about ones I don’t. I struggled to break away from this myopic view of technology for a long time, but as I’ve been slowly introduced to working on larger project, with bigger teams and enormous companies, simply recommending what you like just seems silly.

You’re not going to convince anyone that your framework-de-jour is the best choice just because you’ve used it before, so how do you pick the right tech stack?

Assuming you’re building something for someone else, and not just a side project, you’re responsible for picking the right technology for your client, even if it’s not your favorite.

Much like that old cliche: Favorite frameworks are like assholes, everyone’s got them and they all stink. Given what you’re out to build or who you’re building it for, all frameworks could “stink.”

This is the stuff of flame wars: React vs. Angular. Tabs vs. Spaces. Lennon vs. McCartney.

When it comes down to it, even the fiercest niche-evangelist will eventually admit that most problems can be solved in a wide variety of technologies, so how do you pick? Do you go with the latest & greatest? Most stable? Whatever you’re most familiar with? What has the most support?

Let’s skip over the technical questions we’re used to asking (“The performance benefits of vanilla Javascript,” or “Why VueJs is better than Angular,” or whatever…) — they’ve already been covered ad-nauseam by better writers.

I’m not interested in pitting my favorite framework against yours. The whole point is that we should find the best fit for the client and project. Lets’s leave the flame wars out of it. Lets start by setting clear expectations.

This article is an excerpt from my book The Web Performance Handbook. In it, you will learn the core concepts of web performance, the tools you need to build performant websites, and how to make good performance part of your team’s workflow.

Build better web apps, increase conversion times, and charge your clients more by using what you learn in The Web Performance Handbook.

Setting expectations

Developers spend all day playing with technology. Because of our constant exposure to trends and the constant evolution of technology, we tend to think of software as living things, constantly evolving and changing. That sentiment isn’t always shared by the folks handling the business side of things.

From a high-level perspective, the ebb and flow of technology is abstracted enough to appear stable. Where we see trees, they see a forest.

Nothing is safe, stay flexible

Technology will continue to change. No language, framework or infrastructure you use today will be immune to the shifting sands of time. You can make smarter choices, if you think about your client’s future needs.

No one wants to rebuild something in 2–3 years just because the tech stack is outdated and difficult to maintain. On the other hand, expecting that any software will meet your needs, unchanged, for eternity is unrealistic.

If you think of technology as something you have to plan to “de-risk,” you’re doing it wrong. The world won’t stop changing, why should your tech?

Instead of trying to pick a tech stack that will be stable during the distant nuclear apocalypse, try to make it so easy to change that the business folks get excited about development.

Let’s steer the conversation away from the “cost center” that the maintenance phase obliges and towards a future that makes it super simple to take pieces here and there and tweak/replace/improve when it makes sense.

If a solution is flexible, you shouldn’t need to rebuild everything at any point. Each small part (component, module, or service) can be assessed and changed when the cost/benefit says it should. In that way, future development costs become a tool to grow business, and not the cost of doing business.

Questions I ask

“Hey, client! Eventually, what we build together will be fully maintained by someone in-house. What’s your team look like? What sorts of technology do they like to use? Why?”

Who’s on your team?

For instance, if there’s a big team, split into disciplines like “back end,” “front end,” and “dev ops,” perhaps it makes sense to tackle the technological architecture in a similar way and split things into server-side processes, middleware services layer, and an agnostic presentation layer.

By finding a common denominator, we can ease the burden of the hand-off and improve our odds of being successful down the road.

“Are you hiring anyone currently? What skills are you looking to add to your team? Specialists or generalists? Technical or non-technical? College grads or experienced folks?”

Who do you want to hire in the future?

Bearing in mind that the client’s staff will continue to change, it’s important to understand how they want to grow the team, and what skill they’re currently looking for.

For instance, you might want to prioritize hiring people that are relatively easy to find (which makes them a little cheaper, to boot). This might mean choosing a popular Javascript framework instead of a bleeding-edge distributed blockchain solution.

If their staffing projections predict hiring a lot of post-grads, you might benefit from looking at the learning curve behind any potential technology. Perhaps ReactJS’s reliance on “vanilla” javascript principles might be a better approach than Angular’s proprietary conventions.

“How important is the technology to your business?”

Do they want to be a tech “leader” in the space?

Is it strategically valuable to be using the “hip” frameworks? For really tech-focused companies, their stack can help drive their reputation, hiring, press and marketing efforts.

If they want to be seen as leaders in their space from a technological perspective, you may consider that when selecting a stack. Like, maybe PHP isn’t the best fit for someone looking to add to their growing reputation at multiple Javascript conferences.


Hopefully by thinking about it from a client’s perspective, you’ll be able to pick something you’re happy developing in with the piece of mind that it will suit their needs down the road.

We know the tech, they know the business, and the answer lies somewhere in between. Let’s start to consider the longer-term implications of our choices and be intentional about what we strap into someone’s business for years.

Front End dev + Solution Architect. Read The Web Performance Handbook —

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store