Choosing a Technology Stack for your Startup Product

Jonathan Holloway
6 min readJul 25, 2020

Choosing a technology stack (and as part of that the programming language(s) for your product involves consideration of a number of technical and non-technical factors. Some of the non-technical factors are arguably more important than the technical aspects. Let’s start with outlining some definitions of the technical jargon.

Definitions

Technology Stack — the components that you will use to build your product. That stack will consist of high-level component namely:

  • Frontend — the presentation part of your application — this may be a web frontend or it may be a mobile (iOS, Android) frontend, typically written in Javascript;
  • Backend — the part where all the complex rules, logic and transformation logic live. Your front-end will use this to store, retrieve information etc… can we be written in many different programming languages;
  • Database — where all the information for your product lives

A technology stack has to be hosted somewhere and needs to be written in one or more programming languages. Each part of the technology stack above will consist of one or more libraries and may be based on a framework. Don’t worry too much about the libraries and frameworks for now.

Programming Language — the programming language (and ecosystem) that you’ll build your product with, e.g. Java, Python, Ruby, Javascript etc…

Hosting — the cloud is the default choice these days (Amazon Web Services, Google Cloud Platform, Microsoft Azure). Typically, you’ll be using one of these OR you’ll be using another cloud provider such as Digital Ocean or Heroku. The alternative is to buy your own hardware, install it and then set-up and maintain everything — you really don’t want to do that unless there’s a really really good reason.

Now you might be in the situation as a founder, where you need someone to put all this together and build your product. Let’s look at what options you could use as a founder to build your product.

Product Build Options

You have a few options as a founder for building out your product, namely:

  1. You find an agency (onshore in the UK, or offshore somewhere else in the world) who then proposes a language & technology stack for the product you want them to build.
  2. You find a CTO/technical lead/engineer for your startup. That person will choose the above language/stack.

You might also already have a product, and in that case you’re looking to rebuild using one of the options above. However, if you’re in the initial build phase, you might be wondering:

Should I even care as a founder what stack they use?

What questions should I ask the agency/team?

What are the non-technical implications of the choice?

Technology Stack Examples

Common choices for the backend part of a technology stack are:

  • Javascript and the Node ecosystem — I see it used across the board from early stage to enterprise;
  • Python — early stage to enterprise, also commonly used for “data platforms”;
  • PHP — early stage to enterprise;
  • Java and the JVM — larger companies and enterprises typically;
  • Microsoft and the .NET ecosystem — larger companies and enterprises;

On the front-end web everything is typically based on Javascript. However, you will find engineers who use a different language that compiles down to Javascript.

For mobile, there are a few options:

  • Native iOS (Apple) and Native Android (Google);
  • Cross-platform frameworks such as React Native and Xamarin.

Validation Questions

Here’s a list of questions you need to consider:

Q. How common is the proposed solution?

Is it one of the ones mentioned above. If not, then what’s the rationale behind using it? Does it provide a competitive advantage in a specific way — ask what that is? In some cases, an agency may want to use the solution because they have the people already with these skills, or it’s cheap to find people in their area OR because they’ve always done it this way. In another scenario, you may have a CTO/tech lead/developer who wants to use this to improve their CV and future career possibilities. We call this CV driven development. It’s good for them, but is it good for you?

Q. How big is the pool of engineers for the solution you’re proposing and how does it compare to others?

Is there a large pool of labour resource in the local area that you can take advantage of with the language and technology stack. What’s the average salary that a senior engineer commands in this space? Factor that into your budget when it comes to scaling the business out. It shouldn’t be the deciding choice, but the economic impact of your language and technology stack has to be factored into your decision.

Q. Are you using your own proprietary/bespoke technology in the proposed solution?

This is an important one to ask agencies, particularly because you’ll encounter people who provide their base “agency product framework” to build out your product. Why, because it provides them with a jump-start and saves time when building your product.

That’s the good part, but they may not be upfront/transparent about this and still charge you for the time, or delay starting for a while.

The bad part is this — you’re stuck with it and it doesn’t evolve, unlike an open-source or commercial tech stack. Typically, they’re of poor quality architecturally and structurally as well. Your developers will hate working with it, they will constantly moan.

Be very very wary about agencies proposing such a framework. Your default response is no, I’d like to keep with standard libraries/frameworks.

Q. What support is available commercially or open-source for the technology stack you’re proposing?

Ask the following questions of each part in your tech stack:

  • Does the stack have good documentation explaining how to get things up and running, is it well supported?
  • Is it active and does it have maintainers — look at Github activity here, also look at Stackoverflow for activity in terms of questions. Not you per se, but ask the engineers for the stats in terms of activity;
  • What do engineers currently using this stack say about it? Do they have difficulty with upgrades or getting bug fixes addressed?

Q. Does your in-house team currently have experience with this technology stack?

There has to be clear rationale behind the choice here with the team. This is especially true if the team are transitioning off something they already know and are productive in. Some of the reasons may be:

  • The technology stack we use is awful in terms of productivity — it takes us forever to do things because of bad previous decisions;
  • We can’t find developers with experience of this. Valid, especially if you’re using a language that is niche (e.g. Haskell) or older and less commonly used (Cobol for example). Scaling out here is going to be difficult, in some cases though, you may not need as many developers — that’s a more intricate discussion. Ask yourself, if the person who is proposing this leaves, then where does that leave me in terms of a partially built product?
  • The stack is not optimal for what we need to build here — e.g. we cannot continue to build a data platform out in Javascript, because of poor tooling, libraries or support for what we want to do. We have to build things that we wouldn’t have to in another language ecosystem.

In Conclusion

Of all the job adverts, companies etc… that I see at pre-seed and seed stage, they are either using Javascript, Python or PHP and then others to a latter extent. I’m not saying any of the languages are better than others here, that’s my view of the situation as a Seed to Series-D CTO, talking to lots of other CTO’s and founders in London and the wider UK.

I’m a Consulting CTO at HWIntegral helping startups build and scale their products. If you’re in this situation, in terms of a product build and need advice, you can contact me here.

I am an independent consultant who isn’t affiliated with any agency. I do not provide engineers directly. I provide an independent assessment of your situation, architectural advice and help you engage with the right agency : )

--

--