Minimum Viable Product
Let's think about what a Minimum Viable Product or MVP actually is before we get going. The word was invented and described by Frank Robinson in 2001 and popularized by Steve Blank and Eric Ries. MVP is a software or website that has been created with just enough functionality, that can be published to please early buyers and gain significant input on product growth.
The goal of this production strategy is to accomplish the following objectives:
- Check a low-resource commodity hypothesis
- Bring the solution to early consumers as quickly as possible;
- Reduce missed research hours
- Reduce chances of customer loss from wrong conclusions
Imagine that you have a brilliant business concept for an online marketing tool. You've tested the demand for it, you've made the company open to all of the peers, so it appears to be fantastic, potentially. Your next move is to create a minimum viable product (MVP), but there are simply too many technological choices to be taken and it is too time-consuming to review all of them. Clearly, you just need to make sure that the specifications of the project are fulfilled and that no vital functions are missing.
Both developers should advertise their favorite development stack as the best option for your project, with the goal of selling you as soon as possible , as quickly as possible. You may still do your own separate research, but the amount of information you need is daunting, too many technological buzzwords and descriptions, if you're not a software engineer..
What if you decide later that you do want to open a smartphone app on your website? Having a website code-base that converts well into mobile apps significantly reduces the time and costs of your app's growth.
Choosing a tech stack is the kind of thing that first seems negligible, but it hurts the further the idea goes forward. The more complicated the idea is, the more it costs to switch to new systems.
This sort of flexibility requires a agile tech stack. This is the reason modern developers develop on the JAMstack.
Somewhere down the road, you might consider collaborating with other teams for a number of reasons. Or at least have a chance to do so. If the development in your software is too mysterious, you'll find it hard to replace the dev team. If it's too archaic, the candidates would be senior people who are always hard to find and doesn't justify the cost. Young programmers are cheaper, easier to find, and typically choose modern technology designed for faster development. New technologies are typically popular only because they are are more advanced than their predecessors.
For any major JAMstack application, a back-end is required - more specifically a back-end-as-a-service (BaaS). I've used a few BaaS throughout the years and I find that Google's Firebase is generally the best option for early prototypes. The fact is it works well for both web and mobile apps. If you're looking to target both type of users, then the PWA (progressive web app) might be the thing for you.
What's Firebase
Firebase developed by Google is one of the leading API's on the market for BaaS (Backend-as-a-Service). It let's your front-end link and exchange data between Android , iOS, and web apps. It is an interface that does not need a server setup and can be configured via an online web console. With Firebase's real-time servers, all the data is stored in real-time and can also be continued and analyzed offline.
Based on my experience, I would conclude that Firebase is particularly suitable for building MVPs. Let's break down the benefits and potential drawbacks.
Firebase Advantages
Configuring the Firebase is easy. It allows a quicker start of the project, and can also be built several times more quickly than a Python/Ruby/Php backend.
You can keep an eye on your project in the Firebase console while working, where you can synchronize and upgrade details in real time.
It also comes with a range of built-in benefits that can save many working hours in the future thanks to its advanced security (with fast, secure login) and advanced networking, like HTTPS, etc.
It enables flexible apps to be developed. Scaling a feature in Firebase involves increasing the number of instances of the system being implemented. This is done automatically.
It also provides feedback tracking to assess the performance of the app from the user's point of view, which is incredibly relevant when creating an MVP.
With Firebase, there's no need to think about technology. You can focus on building a bad ass product/service. You don't have to set up servers, update low-level applications, fix bugs, dispute SSL licenses, set up proxies and repositories, load-balancing and back-end workers, etc...the list goes on and on...
You can derive some abstract logic from the accompanying Google Cloud.
So given the above, at the very early stage of developing your MVP, you 're obviously searching for a back-end that promises high performance, doesn't take long to setup, enables an iterative cycle, and is inexpensive for a start-up enterprise. A lot of these things have already been taken care of by the Google Cloud Platform and Firebase for you.