Choosing a Technology Stack for your Startup Product


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

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.

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;
  • 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.

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.



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