Tech choices in startup MVP development

To prepare this article, we consulted two full-stack developers and a DevOps engineer who were all part of the dedicated teams that collaborated on startup MVP development for several Wise clients. Our aim with this publication was to prepare a handy collection of insights our team received working with real businesses and addressing new challenges in the post-covid environment.

The key idea we would like to communicate is that there is no best or right technology stack that would suit any tech product type, be it a mobile app, web application, or SaaS product. If you see this type of narrative in the title or introduction of the article, podcast, or video tutorial, you can freely skip it, as they would be misleading. The truth is, the one-fits-all approach is elusive and there is no right or best. Though there are criteria to consider, jobs to be done, people to involve in the process, as well as mistakes to avoid along the way. We’ll focus on these aspects in this blog.

Before discussing the technology

Prior to starting any considerations related to the technologies you will use, make sure you’ve developed the right MVP mindset and have a clear understanding of what you’re about to build and, most importantly, why.

The key ideas you might want to keep in mind:

• MVP is not a prototype. Users should be able to fully understand the product concept and take it for a proper ride.
• MVP is the best way to test your product with minimum investments.
• Testing means you need to set up an agile development process when you release new functionality constantly.
• Success metrics for your business should be clearly defined.
• The big goal behind the MVP can change. The ability to respond flexibly to the findings you receive is your superpower.

Furthermore, let’s define what is meant by tech stack for the startup MVP development. A technology stack is a combination of tools your in-house or outsourced engineering team will use to create a web, mobile, or cross-platform application. There are usually the client-side (front-end) and server-side (back-end) parts. Tech stack can consist of a variety of tools, services, frameworks, and programming languages. The mix is unique to each specific project and should be assembled based on the requirements and business context of each product separately. Of course, you can delegate the technology choices to your tech partners, but there is no harm in understanding the basic principles of how this process should be done efficiently.

Here’s how we approach the tech stack architecture for the Wise Engineering clients and our in-house startup products.

Start with the right questions

What technology is the best to build a web application? This is a type of question we strongly advise you to avoid. To define the unique mix of technologies for MVP app development, your engineering team should have the mockups in front of them, and the discussion should begin with the following questions:

• What is the core product functionality?
• Who are the users? Where are they located?
• What type of data should be processed? What is their structure?
• Are there marketing campaigns planned? When do we expect user base growth?
• How soon will we need to expand the engineering team?
• What are the time restrictions? Are there due dates set?

All of the aspects above can be broken down into two major categories:

1. Functional products requirements (read: what the product will do). For example, how users will interact with the system, how the platform will respond, authentication steps, what transactions will occur, and more.
2. Quality system or non-functional requirements (read: how the products will perform). For example, how fast the system should perform certain activities, what availability is expected, how dependable the system is, what limits systems should handle, and more.

When it comes to MVP engineering, the non-functional requirements will influence the tech stack choices most of all. Because there are numerous options of how you can realize different features, and, at the same time, when there are high requirements towards security, maintainability, app scalability, and similar, the options range will narrow down significantly.

Avoid over-engineering

In 74% of cases, premature scaling leads to startup failure. Let’s define what is meant by premature scaling or over-engineering.

MVP over-engineering happens when a product acquires more features and advanced setups that the business really needs at the MVP development step. This further leads to the situation when a company's revenue from new users acquisition is lower than the cost of maintaining the system itself. The understanding that, before everything, you create an MVP to build a profitable business and a tech stack only gets you there helps not to fall into the premature scaling trap.

When engaged in MVP development services for startups, the key suggestions we give our clients are the following:

• Do not start MVP web development by writing numerous microservices. This increases debugging time and prolongs the overall development time. You can rearrange the system into microservices gradually after the MVP engineering step is over and you proceed with actual product development.
• When deciding on creating any functionality from scratch applying reasonable buy vs build thinking. Using ready frameworks or services helps decrease product time-to-market and get feedback from the audience faster. Of course, ready-made solutions have lower customization capabilities but do you need that advanced setup to validate the idea and get traction from your MVP? The speed factor wins the competition in most of the cases here.
• For the MVP tech stack, we also recommend selecting up-to-date but proven technologies with extensive engineering communities and an efficient number of developers using them. Of course, using the latest frameworks or programming language is tempting for developers, but this is not the case for your business. You need a stack that consists of proven technologies without any hidden contexts. Plus, once your product scales, hiring more people to the team won’t be an issue.

This, of course, does not mean that the tech stack you select should be simplistic or clunky. Your engineering team should keep the high coding standards and build a system that addresses the business challenges you face and help you achieve your long-term goals.

Define core functionality and stick to it

There is always a temptation to add one more option or more customization to the existing functionality. Yet, for the MVP development step, this is the point where you start to lose focus. To enhance or expand any feature, you need clear and continuous feedback from the audience that they really need it. If the idea to add more functionality belongs to anyone from the team, think twice before adding the task to a backlog.

When the Wise team deals with the MVP development, we focus on building minimum marketable user flow exclusively. Minimum marketable user flow is the simplest feature set that reflects the unique selling proposition of the future product. This is a predefined user flow that allows testing the product from start to the desired state, yet lacks multiple options of how this state can be achieved. We usually have the additional flows documented, but our primary focus never shifts.

We described how to generate a minimum marketable user flow for an MVP development in one of our earlier blog posts.

Consult DevOps before writing any code

Developing and deploying an app constantly and at a fast pace is an integral part of the MVP development process. A DevOps engineer enrolled in the team at the initial steps will set the grounds for an efficient Infrastructure as a Code environment and help your engineering team move along the project roadmap smoothly. The base that will be set at this step will help avoid rearranging the overall system once the scaling is required. DevOps engineers help you think long-term and plan the product architecture for further development and minimize the risk your system will be unable to perform later.

The key task for DevOps at this stage is to allow the product and engineering teams to react flexibly towards the feedback they receive launching an MVP. DevOps engineer is responsible for:

• Setting up Continuous Integration and Continuous Delivery to allow engineers to deploy changes to the product quickly.
• Building a highly available and fault-tolerant system that will allow you to quickly modify or update the application without downtime.
• Orchestrating the engineering team and ensuring wide-scale collaboration across all people involved in the MVP development.
• Setting up system monitoring and autoscaling to prepare the application for any unexpected system loads.
• Initiating product documentation (we’ll talk about this aspect in more detail further).

Learn how we arranged the product architecture when launching auctions and events marketplace from the case study.

Find time for project documentation

Teams dealing with startup launches understand that time-to-market is a vital metric and do everything to reduce it. Still, sparing engineering time by neglecting the aspect of product documentation will negatively impact the development speed soon after new people start joining the team.

A good practice is to start product documentation at the tech stack selection step. You can include the following information:

• What technology did we choose for a specific task?
• Why did we make such a decision?
• What technologies did we consider but didn’t select, and, most importantly, why?

This information will be useful for every new member of the project and save time on R&D steps if similar issues arise again.

At Wise, we are very attentive to product documentation, yet always define a reasonable time to create it. We also recommend keeping up the fast development pace with the efficient environment for code deployment, focusing on user flow that communicates unique product value and not by keeping all the information in the minds of people currently working on the project.

Collect data from day one

Analytics is at the core of the overall MVP idea. You build a minimum viable product to test your hypothesis which is impossible without relevant data collection.

Before starting any steps with MVP planning we always suggest our clients define success factors for their MVP – unique KPIs for their particular business context. These could be both quantitative and qualitative metrics, and it is important to share them with the whole team. From our experience, when everyone involved is aware of the success KPIs and understands the goal behind the MVP step, the team collaborates on the project more effectively.

One of the Wise clients developed an effective approach to MVP creation based on the target audience’s feedback. The team involved the predefined focus group in the evaluation process right from the start. Learn how we developed an MVP for an all-in-one fitness chain platform and learn how the team worked with the focus group’s feedback from the case study. Another our client was using the Mixpanel service very actively to see at what steps we lose a potential client and react iteratively on the UX improvements.

Thus, when you decide what defines your MVP success, collaborate with your tech team to include analytics services in your tech stack.

Never underestimate communication

Communication might be the least expected aspect in the article about the tech stack for MVP, however, from our 15 years experience of launching MVPs for E-commerce, EdTech, Media & Entertainment, and other industries, effective communication contributes to the overall project success.

By effective communication, we mean both communication inside the engineering team, as well as communication between counterparts involved – founders, stakeholders, and investors.

Inside the tech team, the decisions on the chosen tech stack should be well communicated and discussed across back-end, front-end, and DevOps parts. And as was stated above, the decisions should be documented. Besides, the people on the client-side should be also well aware of the tech choices. They might not need to be part of the technology evaluation process, but they should receive a summary of what tech stack was chosen and, most importantly, why, and what the alternatives are.

At Wise, we adopted the client-team approach to communication which helps our client reach out to anyone from the dedicated team. This helps to set an effective communication loop at the step of tech stack selection and ensure efficient collaboration when the MVP development iterations start. Read more about the new communication model in software development outsourcing we apply to the collaboration with our client.

Key takeaways

To architecture a tech stack that will benefit you MVP and allow you to make the most from this product development step, we recommend:

• Analyze both functional and quality system requirements.
• Define marketable user flow and plan MVP development roadmap based on it.
• Schedule DevOps consultation before starting the development.
• Consider project documentation as a long-term investment.
• Define MVP success metrics and set up the analytics right from the start.

At Wise Engineering, we are fluent in different technologies across multiple domains. Check out the tech stacks we usually apply for MVP development for startups and contact us to get tech stack consultation and estimates for your project.