How to choose tech stack for MVP app

It’s easy to get stuck in hype-driven development and choose whatever is newer. However, many moving parts can weigh the scales in favor of one technology or the other. The decision depends on technical factors such as the number of users or the necessity to scale, and something as trivial as your budget restrictions. The latter is usually why early-stage companies decide to stick to the “Rome wasn’t built in a day” rule and begin the software development process with an MVP app.

A short intro to a tech stack

A technology stack is a set of tools, languages, frameworks, and other components of the application environment. As such, it directly impacts the app’s user experience, performance, or even architecture. That’s why when choosing the stack, you should be aware of the pros and cons of the options you have. Only then are you able to match the technology with your app’s requirements.

What makes a tech stack?

When it comes to a tech stack’s composition, it’s a combination of the server-side and client-side technologies. Server-side is where data is processed. It consists of the backend language, framework, web server, database, and operating system.

📚 Here you can read more about the best server-side technologies.

On the other hand, the client-side is where the interaction with the user takes place. Let’s take Netflix as an example. It relies on a powerful server-side system that, among others, processes data and gives recommendations. Next to the engine, we have different client-side applications, meaning the environments where you, as a user, can run Netflix. There’s a mobile app, a web app, SmartTV, AppleTV, etc.

A typical tech stack composition

Why it’s worth to give your stack a thought

When planning for an MVP app, you want to make sure that your product faces the market as soon as possible. After collecting the feedback, you want to easily maintain a quick pace of corrections and new developments, e.g., release the app on new platforms. The right technology allows you to succeed at both stages. What’s more, when the time comes, it will open the door to new team members, either by drawing them with a niche stack or giving tech stability in a startup environment.

There is another side of the coin, though. A hasty decision might cost you time because of a lack of automation tools that support your framework. Let’s take CI/CD tools for mobile as an example. They should speed up the process of testing, versioning, and placing the app in the store. If your framework is very niche, chances are your developers would have to do all this time-consuming stuff manually.  What’s more, in the case of a rising star, you might face unexpected breaking changes that might affect a particular module or entire app architecture. There’s no need to look far back – some banking apps became unmaintainable when AngularJS stopped being supported. Migration to version 2 turned out to be too costly, even for such a sector.

Hype-driven development

There are many technical decisions you need to make as a founder. Your tech stack choice is one of the points at which you might be tempted to ask your programming friends for some recommendations. Chances are you’ll hear about the latest JavaScript frameworks or some niche backend languages such as Go, Rust, or Elixir. That’s natural – developers love to go with the hype and test new technologies. But it doesn’t mean you should experiment with your MVP.

When thinking about the stack for your project, you need to be more far-sighted and pay attention to whether the technology you consider is a fad or an established trend. Going for a brand new (and unstable) framework can become a threat, especially when you get to the point when you are trying to extend your team to find out being niche does not make it easier at all.

What is an MVP

The term Minimum Viable Product was coined in 2001 by Frank Robinson as a product big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Contemporary startup owners, however, might know Eric Ries’ definition of an MVP as a tool for validated learning better.

🚀 And here’s our take on what a Minimum Viable Product is and how to make the most of it.

Whichever definition is closer to your heart, the word minimum will ring loud bells in your ears throughout the entire MVP development process.  

What makes MVP app special

Our experience shows that the most misunderstood characteristic of an MVP, and a trait that makes it different from traditional custom development, is the concept of “minimum”. Minimum refers not only to the scope (which, by the way, should be prioritized and trimmed much more than you expect) but also to the development time and cost. That’s what makes an MVP app different from regular software development projects. Limited release time requires smart decisions or temporary workarounds.

Choosing an MVP tech stack, you need to bear in mind the business aspects of your project and the technical requirements such as:

• Platforms. Unlike a multiplatform project, an MVP often starts with either a web or mobile version, either iOS or Android. If you’re aiming for a mobile application, you’ll probably face the decision of whether to go for Java, Swift, Flutter or React Native. The ultimate choice depends on each technology’s potential to deliver the essential minimum that’s still valuable for the end-users.
• Custom design. Really? Fancy animations, custom illustrations, and UI kit is not a necessity for an MVP. Unless it’s your unique selling point, use a default theme such as Material Design for React applications, and focus on your product’s essence.

What factors to bear in mind when choosing tech stack for an MVP app

Application goal and scope

The point here boils down to how much you are ready to sacrifice to release your MVP as soon as possible. Yes, you heard it right. If your goal is to show an impeccable UX to the investors, get rid of the glitter, focus on the design, and choose an accessible technology that allows the development team to write extremely fast.

Then, once pumped up with cash, get ready to throw the MVP to the trash and build on the stack that can accumulate the fancy features with ease. You might be surprised to see a significantly different set of technologies.

Time and cost

Even though a fair share of our clients realize that the MVP phase requires scope adaptation, translating their vision to a budget is often a bit stressful at the beginning. If it turns out that the estimated time and budget exceed your initial expectations, don’t worry. We’re there for you, ready to help you evaluate which features would be the most beneficial and valuable for your users. Together we’re able to cut to the chase and leave the nice-to-have sprinkles for later. The must-have list you’ll end up with when the dust after the discussions settles will make your MVP indeed a minimum viable product.

⏳ Wondering how to build an MVP in 12 weeks? Check out our guide to launching your product quickly!

To give you a practical example of how the tech stack composition influences the time and cost of MVP development, let us refer to one of our projects: Selfmade Energy. The client approached us equipped with thorough research and a very clear idea in mind. His goal was to build an application that would simplify the process of finding the solar energy provider by means of comparing different vendors’ offerings.

Although price-comparison apps are nothing new, a solution focused on PV systems was one of a kind – which was one of the reasons why we went for an MVP first. Another was the fact that we were dealing with a budget-sensitive project. Bearing these factors and the application’s scope in mind, we decided to begin with a desktop-first solution based on Python and Django. This way, we ensured a smooth integration of the product with the third-party API and shortened the development time to four months. 

Talent pool and community support

Developers have their language preferences. If you have a good team in place, you might want to go with whatever they choose. It can work as long as the team is stable. As a product owner, however, you’ll need to think ahead and look at the stack choice from different perspectives, including a non-technical one. Framework fashions come and go, leaving apps unmaintainable and challenging to develop. The same applies to MVPs, as long as you’re building one intending to add more modules later on.

Stable and well-liked technologies give you access to a broader talent pool and make it easier to fill in potential gaps in your existing team. As shown in a Stack Overflow Survey 2019, hiring a new team member will go smoother if you’re looking for a Python or Java developer, compared to Scala or Go.  What’s more, the more stable a language, the better the community support it has. It means that even the non-obvious use cases are documented, making it a lot easier for the dev team to find the right solutions faster.

Most popular technologies according to Stack Overflow’s Developer Survey 2019

Maintenance and scalability

In the beginning, it’s difficult to say how soon and how fast you'll need to scale. But suppose the preliminary research of your target group (or a seasonal lifecycle of your product) indicates sudden peaks in application load. In that case, you’ll need to prepare for scaling faster than other MVP builders.

In this scenario, cloud computing or microservice architecture might be some of the directions to opt-in for big and complex systems, although not necessarily the most affordable or the best-suited for an MVP. A reliable tech partner should help you make the best choice regarding the entire spectrum of your requirements and a cool-headed, pragmatic calculation.

Now, how about maintenance? Let’s face it. Most startups want to continue developing their imperfect MVPs because too much energy and resources have already been engaged in building them. Hence designing a brand new version with a brand new architecture is out of the question. In such a case, it’s essential to use technology that’s stable and straightforward enough to be easily understood by a regular developer. Otherwise, you risk that adding new features to an old code will take forever.

Security

There’s a saying that the best time to secure your app was yesterday, and the second-best is today. If your MVP app collects any data or belongs to, e.g., healthcare or legal applications, you better design your architecture around security. Robust languages or frameworks, secure databases, appropriate user roles, and encryption comprise the tech stack that supports a high level of protection. If security is your top value, look for languages that implement OWASP Security Knowledge Framework, e.g., PHP, Java, or Go.

A tech stack for your MVP app

With so many available tools and technologies, selecting a tech stack is not a piece of cake. If done right, it will ensure high performance, smooth scalability, and delightful user experience. If done wrong, it can generate financial losses coming from architecture re-designs.

Now you know that making spot-on tech choices for an MVP does not boil down to asking your team “which technology do you like to work with?”. There are more nuances to consider, especially if the MVP is going to be a scaffold for future development.

Get in touch with our software consultants today to prevent costly rework and turn your MVP into a success!