Building an MVP? Once you have decided all the features that go into it, the important decision remains about your technology and architecture. Architecture is the glue that holds all of your technology decisions together; hence, it is important to take a cautious step towards getting your architecture right.
So what should drive your architectural decisions? There can be many reasons that define your architecture, but primarily it would be about what you want and expect from your product.
A product usually has 3 stages in its journey.
- Hypothesis- You want to get to market asap. All you want is things to work satisfactorily, not fail or show error and manage the incoming traffic, usually upto a couple of thousands.
- Growth- You get signs that your product is growing, traffic is increasing, and you want to build more features fast. Architecture expectations at this point would be about making things stable and secure. Have modularity to add more features and be able to manage workloads as well as monitor any surprises.
- Establishment- You now have tens of thousands of paying users. The company has layers of people, and a product roadmap is established not only for immediate use but also for upto 2-3 years. Architecture is now meant for managing.
Now that you have understood at a high level, here are some questions that can help you make your decision
- Expected number of users at the launch?
- Expected number of users in the first 6 months?
- Expected number of users in a year?
- A number of transactions expected per day, per hour, per second?
- Any special requirements for compliance or security?
- Any special requirements for availability, backup, and content type?
- Any budgeting constraints on spending on hosting and infrastructure?
To Read full article click here: A Guide To Minimum Viable Architecture Points For Any Startup
The whole startup world has become inspired by the idea of building Minimum Viable Products (MVPs) after Eric Ries popularised it back in 2008. It has become a trendy word in the tech world gradually turning into a misleading concept.
As a result, we have companies that are not willing to use the MVP approach as they don’t 100% understand it, experts who state the concept is wrong and clients who often get hot under the collar after the suggestion to try out a minimum viable product.
Сonsidering the fact that MVP remains one of the most important components when creating software, it would be unreasonable to drop it just because some people misuse the concept.
Let’s talk about why this lean tool becomes confusing, what mistakes you should avoid and, more to the point, what is the right way to build an MVP.
In a simple phrase, an MVP meaning is a product, which includes minimum features, or one main feature.
Well, there are lots of reasons, and the main is that customers can start using it before the overall product appears.
Thus, a user gets acquainted with the idea or concept of the future, more complex product and even can influence on its development.
In such a way, the product owner can create an app, which satisfies his and customers' requirements.
Yet, lots of startupers are prejudiced against such development method.
They are frightened that they won't be able to show the overall idea with an MVP model.
MVP is the first target version of your dream product. They consume less time and less cost. But what comes next after MVP?
As you agreed that you’re building an MVP, this means you should not prolong the development stage.
At first, you need to make sure what your target customer is exactly looking for. Since you cannot lose the idea-gems just because it is not the perfect time.
It is better to postpone the extra features and add them after the MVP becomes a success. You can prioritize and put them in an order you want to build them.
Since, most startups feel that after the MVP is ready and validated, they will start working on the final product and everything will settle in their favor.
