Start-ups often face dilemmas when choosing the technology for building an MVP (Minimum Viable Product).
Wrong technology decisions can be compared to a bad marriage; they invite more trouble if you don’t address issues promptly. I realized this while working with a customer whose product was initially paired with an unsuitable technology by their CTO. This mismatch caused gaps that widened over time, making the adoption of new technologies increasingly difficult.
There are 5 significant technical decisions that start-ups should consider to build a scalable MVP.
Learn more about MVP Software Development: Complete Guide for Startups
Using Microservices architecture pattern to build an MVP
Microservices architecture has become a buzzword now. You go to any seminar or talk, and this topic would invariably pop during conversations. OSS platforms like Netflix and others have fanned this sudden surge in popularity of the technology as it helped them accelerate their development and deployment. But is this technology a must for all? I say, ‘No.’
Microservices architecture is suitable only when the following two conditions back it up:
High scale
This pattern is suitable for services where billions of requests pour in each day. We used this to develop an ad server with similar criteria and earned favorable results. But such cases are exceptions- scaling billions from Day 1 is a colossal task and rarely happens.
Large teams & Agility
The number of members in a team is also crucial. My personal opinion is a team with more than 100 members and a strong business need for agility are the possible use cases for microservices.
Let me share an experience. In 2016, we used microservices to build an MVP as its hype was high. Microservices architecture is inherently distributed- their complexities made iterations frequent, which prevented us from meeting deadlines. Finally, we rolled out the MVP after a year instead of our initial plan to launch it within 6 months.
We had to fight real hard with distributed transactions, debugging was tough, and even simple user stories had complexities. The complexities we encountered were unprecedented. Distributed systems are hard to manage: the team had to implement complex patterns like outbox patterns and circuit breakers for transactional integrity and reliability. Over time, these patterns matured, but it made me think, “Is this kind of complexity necessary? Is the ROI worth the trouble?” The answer was negative.
Before considering the Microservices for your start-up, ask these two questions – Do we need to support billions of requests every day? Am I going to ramp up my development team to 100+ engineers in a couple of years? If the answers are ‘No,’ do not go ahead. Instead, adopt the Modular Monolith. Like microservices, it comes with a database for each module that allows parallel development to an extent, but it is deployed as a single unit removing the complexities of distributed systems to another day.
Know more about In-House Vs. Offshore Software Development Team- Which One Should You Pick?
Using NoSQL Stores without a specific need to build an MVP
When it comes to NoSQL, a lot of entrepreneurs or programmers are well-versed with the concept of 3Vs-
- Volume
- Variety
- Velocity
NoSQL is suited for problems where the product velocity demands support for billions of requests or generates around 1TB of data each day. Also, if there is a constant influx of structured, semi-structured, or unstructured data, then NoSQL is necessary.
Its use in the flexible schema is widespread where one is not sure about the entity attributes as entities evolve. For instance, e-commerce sites are its biggest takers as RDBMS cannot provide flexibility to store the inventory. NoSQL is benefiting from such scenarios and cashing on the popularity of databases like Redis, MongoDB, and Cassandra. It has already covered 39.52% of the market.
However, there are cases where using NoSQL can usher in disaster. A few years back, I was building an MVP for a fintech startup. Our choice of Aerospike as the DB for our transactional store turned out to be wrong. It does not support ACID guarantees, so we had to go with BASE (Basically Available Soft state Eventual consistency), which is operationally intensive and adds to the time, effort, and cost.
We ended up fighting the wrong battles. If volume, variety, and velocity are not your prerequisites, then don’t take up NoSQL. For such cases, RDMS is a good option.
Another aspect that gets neglected often during decision-making is the expertise in data modeling NoSQL stores. Data modeling in NoSQL is different from RDBMS. For a practical application of NoSQL, understanding the query pattern is of prime importance, and modeling is done based on UX screens and query patterns instead of normalization techniques.
Moreover, with Mongo or Couchbase, the internal storage structure can give rise to more complexities. Then there is the pricing strategy – Dynamo and CosmosDB and similar engines, but their pricing strategies are entirely different. A shift to NoSQL would require more time to understand these models. If your venture gets support from freelancers with RDBMS background, then stick to RDBMS to keep things simple.
Using the standard test pyramid strategy for test automation
Software testing is fast becoming a trend and around 78% of companies are now relying on it. To test tools, clients follow a pyramid:
In 2012, I got this opportunity to work on a platform called 1-9-90. In any social media platform, there are 1% influencers, 9% active users, and 90% passive users. The idea was to create content on our platform and publish it on different social media platforms to collect engagement using views, subscribers, shares, etc. But after 6 months, the company decided to change its stance. The intent was to understand how the brand is performing, which led us to build the Digital Consumer Intelligence Platform. We shifted from a content creator play to an API-only service. We had to scrap most of the test automation we had so painstakingly built.
What most people don’t realize is that Test automation is hard and often brittle in nature. You need adept developers and QA engineers working together to create a state-of-the-art regression suite. Like the DevOps movement and DesignOps movement, a DevQA movement is the need of the hour to write tests and ensure ROI that most teams fail to realize. If not performed precisely, the ROI will take a hit. For startups, I would recommend a test diamond-
It comprises module-specific unit tests, a lot of integration tests, and a few end-to-end tests. Ideally, develop test automation only if the product is market fit.
Having no objective targets for MVP
The most challenging question for a Product Owner is – How will you objectively define the MVP’s success? Mostly, they know the problem and the solution but fail to put it across objectively in measurable terms.
In an earlier opportunity where we had a chance to work with a payment gateway, the MVP’s goal was to reduce checkout time. Instead of 30 seconds to complete a checkout flow, the process needed to happen within 10 seconds – this metric gave the team a clear, measurable objective. They could fine-tune the feature set and user experience until they achieved the said target.
Such clarity helps the team apply Customer Developer Principles, wherein you learn, measure, and iterate to meet your goals. Having said this, converting a feature goal into a measurable metric is not very easy and straightforward. It needs creativity, expertise, and Analytics tools to get things right.
Another mistake that some startups make is to focus their energies on building the bells and whistles. Entrepreneurs are incredibly passionate about their problems and they keep coming up with new ideas and ways to solve the problem. Dropping the current strategy and running after a new one is widespread among startup teams. Such actions confuse teams and often misguide them. Having a well-defined, measurable target helps the team validate pivots objectively.
Companies must stay away from bells and whistles as they spur production costs and delay the time to market. In my opinion, always focus on building a key differentiator, and define the success of an MVP objectively to help the team stay aligned.
Poor Build vs. Buy Decisions
There are two clear-cut ways of empowering an MVP-
- Build
- Buy
Entrepreneurs often try to build everything from scratch and as an engineer, I would love such opportunities. But is it profitable for your MVP? You have to measure it in terms of cost, time, and effort. In most cases, I have found that buying is a pragmatic way forward.
Read also: software development guide for startups
If you have a unique business model where you need a new algorithm, which is also a differentiator, then don’t shy away from building one. But if your algorithm is not the star, there buy one and then optimize it.
A more dynamic approach would be to follow a Buy, Validate, and Build Methodology. In an earlier opportunity where we had a chance to work with a payment gateway, our client bought a payment aggregator’s license instead of building it. The goal of the MVP was to reduce the time of checkout and enhance the experience – which could be achieved without building the complete payment aggregator from scratch.
As a solution, we loaded it with features that solved the primary problem and fetched us paying customers. Then we replaced the payment aggregator with our own to improve margins. This helped us get the MVP ready on time and open the revenue stream, get the product-market-fit and then work on profitability. The Buy-Validate-Build Methodology helped us validate and fail fast!
Also Read Case Study- MVP to Enterprise Ready
To summarize, consider these technology decisions while building MVP
- Avoid Microservices. Use Modular Monolith
- Avoid NoSQL stores. RDBMS still works for most cases
- Do not do Test Automation till you reach Product-Market Fit
- Do not build bells & whistles, have objective MVP Goals
- Make Pragmatic Buy decisions, don’t build everything
