How to Choose Your Tech Stack

An MVP is all about getting a product into the hands of your customers quickly and learning from their feedback. Importantly, it also serves as a foundation for your engineering team to build on as your company grows.

Before any code gets written, you will need to select the tech stack that will power your application. Selecting a tech stack is often a hard decision for founders to navigate. The options are overwhelming if you are non-technical, and they come with a fear that committing to the wrong language or framework will have serious consequences down the road.

In reality, there are only a few key factors to consider during the decision process, and you can quickly narrow the options down to a manageable set of technology choices. Your first step should be clearing away the fog around the term “tech stack” so you can mentally place each technology in its correct category.

What is a tech stack?

A tech stack is a combination of software products and programming languages used to create a web or mobile application. Applications have two software components: client-side and server-side, also known as front-end and back-end. Each layer of the application builds on the features of the one below it, creating a stack. This diagram shows the major building blocks of a typical tech stack, but there can be other supporting components included.

Back-end tech stack

The back-end contains the business logic that works behind the scenes to drive your application.

Users will never directly engage with the back-end, all information is passed back and forth through the front-end. The most well known example of a back-end tech stack is the LAMP stack (Linux, Apache, MySQL, PHP). More recent variations of this stack include Ruby or Python as the programming language instead of PHP. A programming language is selected along with a web framework written in that language. Frameworks are incredibly useful because they provide developers with vetted implementations of common web application features like user authentication and data access, saving them from re-inventing the wheel. Popular framework choices include:

Front-end tech stack

The front-end is the visual part of your application that users will see and interact with. This interaction can happen through a web browser or a mobile app. When building for the web, the front-end tech stack is made up of:

• HTML (Markup Language)
• CSS (Style Sheet Language)
• JavaScript (Scripting Language)

Front-end frameworks are optional, though recommended:

• JavaScript frameworks include tools for building rich, interactive web experiences. Recommended: AngularJS, Backbone.js, ReactJS
• Presentation frameworks provide a standardized format for creating responsive web pages with clean aesthetics. Recommended: Bootstrap

For a mobile app the tech stack is simply comprised of an iOS or Android app written in Objective-C/SWIFT or Java, respectively.

How should I choose a tech stack?

If you are a non-technical founder, it’s tempting to find the nearest developer and rely on their advice when choosing a tech stack. However, developers may be biased towards the technology tools with which they are most comfortable, or judge technologies purely on technical merits rather than business needs. We’ve found the following three step process to be a more objective way of evaluating different technology options.

1. Mobile or Web? Design for your target user base

More than 60% of web traffic now comes from mobile devices, and 25% of Americans use only mobile devices to access the internet. These trends will continue to accelerate, so incorporating mobile into your strategy is only a question of when, not if.

However, you shouldn’t rely just on general statistics. Refer to the key constituents you identified when designing your MVP and the value proposition your product will offer them. Are users more likely to engage with your product on their phone while on the go, or while sitting at a desk in their office? You should generally launch your MVP on only one platform – mobile or web. Spending the additional resources to build and maintain two separate interfaces is better justified after you have made progress in validating your product.

With the big picture in mind, the usage patterns of your particular audience will guide you towards a mobile first, mobile only, or mobile later design approach.

Mobile first

The term “mobile first design” means building a responsive web app that adjusts well to all screen sizes, but making sure the UI looks great on a small mobile screen first.

Responsive web apps are easy to discover through a google search or a shared link and instantly available without downloading anything. They are cheaper to develop than native apps and easier to iterate on, serving as a useful tool for quickly validating your product. Launch with a responsive web app if your product:

• Serves content to a broad audience of desktop and mobile users
• Contains rich material that can be leveraged for SEO
• Has a simple UI that can be navigated without frustration on a mobile browser

Examples: Etsy, Vimeo, Scribd

Mobile only

In a mobile only approach your MVP will be offered exclusively as a native mobile app downloaded from the app store. Mobile users expect interfaces that look great and work smoothly, and native apps offer the best experience.

It is generally advised to develop an iOS app for an MVP and only later add an Android version.

Even though Android holds a larger market share with 52% in the US and 80% worldwide, the need to support hundreds of different devices makes it more cumbersome to develop for. There are more than enough iOS users to validate your product and they tend to be more engaged, spending four times as much as Android users. Launching with both will significantly increase your time to market, and you’ll be doing twice the work on every product iteration. Launch with a native app if your product:

• Will be used primarily on mobile
• Needs access to device features like the camera, GPS, or accelerometer
• Will benefit from real-time interactions like push notifications and micro purchases

Examples: Instagram, WhatsApp, Uber, Waze

Mobile later

In some cases, an MVP should be a traditional web app with no consideration given to mobile design. For example, many SaaS products are targeted at business users who mainly interact with the product through a desktop or laptop browser. A companion mobile app that provides complementary functionality can be developed later. Launch with a traditional web app if your product:

• Will be used primarily on a desktop or laptop
• Requires a complex user interface
• Accepts file uploads like spreadsheets or large images

Examples: MailChimp, ZenDesk, Xero  

2. Consider the landscape of tools in your industry

One of the keys to a successful MVP is reducing time to market. Capitalizing on existing tools can dramatically reduce the scope of work and effort required to launch your product.

When selecting a programming language and other back-end technologies, first identify the best open source tools available in your industry and use their tech stack as a guide.

Note: If you are launching with only a simple native mobile application you should use a back-end provider like Parse or StackMob instead of developing your own. Don’t rely just on market share, look for recent development on Github from a wide variety of contributors and a large number of StackOverflow questions. The best tools have a vibrant and enthusiastic developer community around them. In the ecommerce space, for example, Magento is the biggest player with 25% market share and an installed base of 250,000 websites. Spree is a newer platform with an installed base of only 5,000 websites. However, it has over 500 active contributors, ranking it in the top 50 open source projects worldwide. Spree is a very likely a better choice if you are starting a new ecommerce project, and since it is written in Ruby that would influence your choice of back-end programming language.  

3. Who is going to build this thing?

Shortage of engineering talent is a major challenge for early stage startups. As a result, the availability of engineering team members will play a role in determining the right tech stack for your company.

Certain tech stacks attract different types of candidates and will influence your company culture. Many talented developers are excited by the prospect of working with latest tools, and actively avoid technologies that aren’t considered innovative. For example, PHP is the most common language used to build web apps, but it has a bad reputation. This reputation is so pervasive that some companies even feel the need to apologize for using it!

When choosing a tech stack make sure there are enough engineers in your area with the skills you require. A fun new technology like NodeJS might attract your preferred cultural fit, but you will be recruiting from a relatively limited talent pool.

Available talent also varies by industry. For example, financial tech platforms have historically been built using Java or .NET because of regulatory and compliance issues. Even though these languages are often looked down upon by the startup community, if you are operating in the financial sector they have merits and can open up a larger pool of candidates.

Will my tech stack scale? Choosing a tech stack is a commitment that’s not easily reversed, so concerns related to future circumstances like scalability and performance are common. However, trying to address these concerns at the MVP stage would be premature. Many performance issues are a product of application design, not technology choice. They can be resolved through tuning and optimization, and you’ll have a bigger budget to deal with them as you grow. Following the decision process outlined above will leave you with a tech stack that will serve you well for your MVP and well beyond.

Become A Client