With the prevalence of open-source frameworks and technologies, it is increasingly easy to rapidly develop a robust Minimum Viable Product (MVP). Infrastructure provided by companies such as Heroku and major cloud providers also make it easy to ensure uptime when the product takes off, permitting resources to scale automatically as needed.
Yet, the tech stack chosen early in the process can have longer-term consequences if not careful.
Last year, I spent the summer migrating services into Google Cloud Platform from a Virtual Private Server provider. This was fairly straightforward as we didn't need to leverage any cloud specific service. The cloud infrastructure also allowed us to increase our data processing capabilities as our data intake and output grew.
Since then, I began exploring other services provided by Google, such as Firebase, to evaluate the trade-offs of its use for MVP development. Firebase is a good option for MVP development, providing a generous free tier so products can be easily tested at a low cost.
As I began chatting with other entrepreneurs with different needs for their MVP - subscription payments, document signing, image processing, user recommendations and matchmaking, chat rooms, etc., I quickly realized that Firebase would not be as flexible as other options on the table and ultimately would have a high switching cost if a migration to another service would be necessary. That doesn't mean it's a bad option - just perhaps not the best depending on the product.
I began considering how to evaluate solutions based on portability and long-term resilience for different product features and business models. Here are a few metrics I identified to evaluate different solutions for MVP development:
- User Base (demographics, device access, # users, etc.)
- Location
- Growth Strategy
- Customer Acquisition
- Development Team
User Base
Who is the target customer? What problem is it solving? It's important to understand why and how a user will engage with the product. Demographics also matter, because different groups will have different habits for engaging the platform. All of this impacts the user experience. The user base may dictate how fast the product may need to scale, what type of requests you'll need to support, and how much data you'll need to process.
Location
Is the product for a specific geography or targeting different cities/countries/regions? Most MVPs will only be for a single country or even a single city. But some MVPs may target multiple geographies that may require redundant infrastructure in different geographic regions to reduce latency. If you'll need to set up the same platform in a different geographic region, you'll want to ensure the setup process is easy and seamless. This requires some consideration on the deployment process. There may also be different data processing requirements based on geography, which is also necessary to keep in mind as it may impact your data collection requirements (or limitations).
Growth Strategy
What is the growth timeline? When do you want to ramp up customer acquisition? What is driving this need for growth? I personally favor organic growth, though everyone has different motivations for how fast they target growth. Keep in mind though that growing too fast may also result in high infrastructure costs if you're platform isn't ready to easily scale. Poorly written code can also easily lead to longer request processing times, which may be solved by throwing hardware at the problem, but also increases hosting costs. It's better to avoid such problems, but numerous factors can contribute to its inevitable appearance, which are not always easy to predict.
Customer Acquisition
Every platform is different when it comes to acquiring customers. There are many strategies for targeting new customers. For the purpose of discussing MVP technology strategy, I'm going to focus on service integration as related to customer acquisition. Various customer acquisition strategies require integration with existing services that already offer a unique service. For example, a common one is Google Authentication. Platforms that allow users to sign-in with their existing Google account lower the barrier of acquiring a new customer because it saves the customer time from having to fill out and register for a new service. While integrations are great, they can become headaches down the road as the product team is required to maintain the various integrations. API changes to services will also require platform updates to adapt to the new service or risk a breaking change. Too many integrations may add on more technical debt than the absence of integrations.
Development Team
Some founders aim to develop the product internally after an MVP is developed. Others may opt for a development agency to maintain the platform for them. This is usually determined through a combination of product vision, growth strategy, and founder preference. If it's the former, it's important for the tech stack to be built on common and popular frameworks/languages to allow for an easy transition and an easy adoption by a new team. The latter works well for highly specialized products, where best practices have been refined and established through multiple product iterations. It also works well for niche markets.
The Tech
Based on these metrics, I've settled on the following tech combinations:
Frontend:
- Vue.js
- Vuetify
- Quasar
- Gridsome
Backend:
- Sails.js
- Firebase
Integration Services:
- Stripe
- Sendgrid
Hosting:
- Google Cloud
- Heroku
- Netlify
These are my recommendations for most MVPs, based on my framework prefrence. The above evaluation metrics allow me to define precisely which combination of the above are used to develop an MVP.
Discuss
What metrics do you use to determine a tech stack? What's your go-to stack?
Top comments (0)