5 Key Technology Decisions for a Scalable MVP
Editor - 06 January 2021 -
Editor - 06 January 2021 -
Wrong technology decisions are like a bad marriage. If you linger around it for long, then be prepared for more troubles. I realized this while working with a customer whose product was matched with an inexact technology by a CTO at an initial stage.
Over time, the rift between them widened, and adopting new technologies became more difficult. This led me to think of dilemmas that startups often face while zeroing in on technology.
There are 5 significant technical decisions that startups should consider before they start building a scalable MVP.
Microservices architecture has become a buzzword now. You go to any seminar or talk, and you will find this as a hot cake selling fast. It got the thrust from OSS platforms like Netflix and others after it helped accelerate the development and deployment of such platforms and services. The accolades are well-earned. But is it a must for all? I say, ‘No.’
Microservices architecture is good only when the following two conditions back it up:
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 a number like that from Day 1 is a huge task and it rarely happens.
Large teams & Agility
The other factor is the number of members in a team. My personal opinion is a team with more than 100 members and a strong business need for agility are possible use cases for microservices.
Let me share an experience. In 2016, we used microservices to build an MVP as the hype surrounding it was high. Microservices architecture is inherently distributed- their complexities made iterations frequent and deadlines got delayed. 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 level of complexities we encountered was 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 have matured but it pushed me to think, “Is this kind of complexity necessary? Is the ROI that much alluring?” The answer was negative.
Before considering the Microservices journey for your startup, ask these two questions – Do we need to support billions of requests every day? Will I 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.
When it comes to NoSQL, a lot of entrepreneurs or programmers are well-versed with the concept of 3Vs-
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 developing 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.
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.
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, define the success of an MVP objectively to help the team stay aligned.
There are two clear-cut ways of empowering an MVP-
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.
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!
To summarize, consider these technology decisions while building MVP