Your mobile app tech stack (that is, front-end plus back-end components) determines the speed and timeline of your app development process. Consider product, project, and iteration speed as you make your tech stack choice.

When you begin building any type of technology, you find yourself down some deep research rabbit holes while building your tech stack (that is, the set of software components that make an app). You start looking for a developer who can write Angular JS or Meteor all because a stranger in some forum told you to.

Here’s the reality: A single tech stack doesn’t work for every development scenario. The ideal tech stack for your mobile app depends on your situation. Over the years, we’ve realized that the process for finding the right language or framework takes time and effort.

When you get it right, a quality tech stack is an often-overlooked competitive advantage. I know this from experience. My team at MindSea has helped dozens of businesses better understand which technology they should use to build their mobile app.

In this post, I’ll review what you should consider when making your tech stack choice.

Here’s Why You Want to Get Your Tech Stack Right

A tech stack is a combination of software and programming languages.

The majority of mobile application tech stacks have two elements: client side and server side, also known as the front-end and back-end, respectively.

Here’s a visual representation of a tech stack:

Source: Silicon Valley Software Group

The back-end (server-side) is where data and business logic come together to deliver your product’s primary functionality. Your users will never directly interact with the back-end; the back-end sends all necessary information to the front end, which serves it up in a user-friendly way.

Using the wrong tech stack can be costly and set projects back months.

A common mistake is planning for huge scale before you’ve even launched. If you’re working on an early-stage product, it might seem exciting to go with the most popular tech stack. However, you could waste your time if you’re trying to create something on the latest stack just because it’s hot.

Dave Girouard, CEO of Upstart and former president of Google Enterprise Apps, talks about speed as a habit in an article for First Round:

I’ve long believed that speed is the ultimate weapon in business. All else being equal, the fastest company in any market will win. Speed is a defining characteristic — if not the defining characteristic — of the leader in virtually every industry you look at.

When it comes to picking an optimal tech stack, there’s no question that speed is an important part of the equation. But speed means a few different things.

Let’s discuss three types of speed.

1. Product Speed

The first is product speed, which is an aspect of user experience. User experience (UX) refers to how the app responds in the moment as the user interacts with it. A quality UX is key since it means retaining users and receiving five-star reviews.

The design and feel of an app are crucial parts of UX, but speed is also a key factor.

From a front-end standpoint, product speed means the speed of the experience but also the speed at which customers become familiar with the app and its interface.

Some audiences are more familiar (and therefore comfortable) with native apps over web apps. Compuware found that 85% of consumers strongly favor apps. The most common reasons: convenience, speed, and ease of browsing.

This audience familiarity helps you determine whether you use Objective-C, Swift, or Java to create that native experience or React or Angular to create a desktop experience.

2. Iteration Speed

Iteration speed is a team's ability to repeatedly learn and then act on those learnings through code or design. If your team isn’t familiar with the languages you use, your iteration speed will slow down.

The best way for a company to increase its chances of success is to increase its iteration speed. To do this, your business must decrease the development time and overheads time, according to Wojtek Skalski:

Development time means how long you spend on programming, testing, developing, and deploying your product. Overheads time is the time required to deploy A/B tests, conduct research, and have discussions about what’s next.

If your team isn’t familiar with your chosen tech stack, development time slows as team members learn how to write the code.

If you choose the wrong stack, the stack’s limitations will become clear. Members of your team might spin their wheels as they try to code, increasing overheads time.

When this happens, organizations often push for workarounds that take even more time. They might also choose to start from scratch: an even bigger drain on resources and time.

3. Project Speed

Finally, think about project speed, or the amount of time it takes you to get from idea to launch.

If you’re building an enterprise solution for a Fortune 500 brand, the timeline is likely long, since you’re launching to an existing audience.

If you’re a startup, though, you’re trying to get your app to early adopters in order to break into the market. Generally, startups can rely on a simpler, leaner tech stack, since they’re focusing on getting an MVP (minimum viable product) in users’ hands.

What Questions Should You Ask When Picking Your Tech Stack?

The team at Quick Left offers a great series of questions to ask when considering the different frameworks for mobile apps. We’ve combined a few of our own with Quick Left's list to give you a list of questions that every team should think about before picking its tech stack.

Here’s a few from Quick Left:

Is it well-documented?

Is there an active community around it?

If it’s a new framework, how quickly is it changing?

Does it have corporate backers? If so, what is their track record in supporting technologies?

Is it easy to test?

How difficult will it be to hire developers to work on it?

What does the ramp-up time for learning it look like?

Is there something unique about your business needs that only this technology can provide?

When it comes to hosting and DevOps, do you have resources available to support changes on your own, or does it make sense to pay for a Platform as a Service provider like Heroku or Engine Yard?

And here are a couple of the questions we also like to ask:

Any regulatory concerns (e.g. data has to stay in/out of country X)?

Do you already build or maintain web services?

How much downtime can you handle (we stream audio -> none; content updates once a week -> a lot)?

Are there any other APIs we need to integrate with, and how painful are they?

As you think about these questions, remember that there are no right or wrong answers. The intent is to gain as much insight as possible about the technical requirements of your app. Asking these questions will make it easy to make the right tech stack decisions.

Your Tech Stack is Your App’s Foundation

There’s no question that picking the right tech stack is an important decision.

I’ve explained why the choice matters, but exactly which technologies you should embrace depends on you. There are no cookie-cutter stacks that work for everyone.

We hope that this article has helped you understand the tech stack as well as approach the tech stack choice with the knowledge you need.

About the Author

Bill Wilson is the founder and CEO of the mobile design and development studio MindSea, where he helps brands go mobile through creative mobile app solutions. Over the years, he's been a mentor to many entrepreneurs and a guest lecturer at universities discussing the power of mobile.