My System for Choosing Tech

When you come to choose a tech stack for a main portion of your business, I always advise taking into account 3 different metrics.

Note: this discussion is about long-term solutions, and doesn’t hold for quick, POC-like needs. Look for those in a different post.

Core: Whether or not this is addressing something in your business that is the core of your business and so is important to deliver high quality, consistently and rapidly in.

Novelty: Is this answering a need in a way that is new and innovating, or is this something that is common and has been solved a hundred times already.

Talent: Whether your team (and to a lesser extent, the available pool of talent in your area) has an advantage in a specific solution.

Realize where your problem is located on this diagram:

From this point on, these guidelines usually work out, according to which segment you land on:

  1. This is a very important problem, as it is both at the core of your business are requires a novel approach. Since your team has an advantage with a related tech, most often that would be the right choice, unless the novelty requires innovation that the known solutions can’t provide. Something this important means you have to be able to deliver reliably and fast.
  2. A problem that requires novelty yet isn’t part of your core business is usually a peripheral service that can allow you to achieve better results. Examples are innovative analytics solutions to help the product team, or advanced automated marketing solutions that aren’t the product you’re actually “selling.” The talent advantage means it’s a good place to let the team cruise in their comfort zone and reap rewards quickly, unless innovation needed requires a special solution.
  3. When in need of something novel and it is at the core of your business, though you have no existing experience, I tend to reach for a solution that has an active and viable community, with an upward trend. It doesn’t have to be the safest or most stable choice, but it does need to be alive and productive.
  4. Something that’s a core of your business yet requires no novelty is a standard problem that’s important, yet has been solved many times over. For example a simple REST API, a standard user-facing web app, etc. Given that the team has experience with something in this space, just go with it. No need to go wild, as it’s a “boring” problem and innovation here won’t likely help your business.
  5. This is something extremely peripheral, as it’s not in the core of the business and has no need of novelty. I’d suggest simply using whatever the team is used to instead of wasting cycles here. Usually in the form of authentication mechanisms, email sending capabilities, and similar.
  6. An interesting problem to have: something that isn’t at the core of the business, yet requires some innovation and your team is agnostic about an existing solution. This is the prime option for trying out whatever is hot and new and letting the team experiment. New solutions are usually easier to innovate with, yet as this isn’t something too important, the cost of choosing wrong isn’t too great.
  7. The counterpart of option 4, given the team has no prior experience you should probably pick one of the big, known, stable and boring options. No one wants to spend time on a trivial piece of software, especially when it’s important to your operation.

These guidelines are the basic point from which we start discussions and validated. And always keep in mind that complexifying things isn’t the goal.