MVP: myths vs. reality of tech product development

How the venture builder Digital Horizon manages to build MVPs that don’t drain the budget, instead evolving into successful tech products.

The first step to implementing any innovation is to develop an MVP (Minimal Viable Product). But it often turns out to be the last stage for many projects, with reasons ranging from low market demand for the idea to a lack of funding. This is why it’s important to understand the difference between MVPs that fail and the ones that escape the “valley of death.”

In this interview, Yury Chumin, CTO at venture builder Digital Horizon, spoke about:

• why an MVP shouldn’t be built based on an idea;
• when monolithic architecture is better than microservices;
• why product managers and marketers need MVPs without development;
• what makes a throwaway MVP;
• how much building an MVP costs;
• why T-shape developers are better than full-stack developers for a venture builder;
• who he wants to add to his team (spoiler — experts in Java, Python, Golang) and what kinds of rules apply;
• where IT development is heading.

Yury Chumin, CTO at venture builder Digital Horizon

Yury received a Bachelor’s degree in Applied Mathematics at the Moscow Aviation Institute and has been working in IT for over 20 years. He spent the first half of his career working with big data and information security in cell communication networks. He used to develop subscriber analytics systems, generate geo-reports, and score bank customers at MTS and other telecom companies.

In 2018, he joined the venture builder Digital Horizon. In the beginning, he worked on the crypto-fiat project Aximetria and then on the cashback service PayReverse. Since 2021, Yuri has been the CTO of the entire venture builder.

How to build a strong foundation for an MVP

— Yury, what does a CTO of a venture builder do?

A venture builder creates promising tech businesses, and my role in the venture builder is centered around IT product implementation — I develop the architecture for new products and manage the development team.

We either create a final product for an external customer or implement our own ideas. Part of our core expertise is in building MVPs, which are subsequently scaled up to amazing full-featured services.

Venture builder Digital Horizon launches businesses that attract investors and have the potential to become market leaders. Our team has built eight projects in three years. Some of the companies in our portfolio are the open banking API platform Apibank, the financial service Aximetria, the blockchain trade finance platform Factorin, and the digital marketing manager Max.

— Imagine that you are approached by a team or an external customer, and they say: “We have an idea. Let’s put together an MVP. “ What’s your first question?

I will ask about the stage of development of their business model. You should never start developing a product with just an idea. Even if you’re building an e-store, you first analyze the market, product positioning, and competitors. You need to understand how to enter this market. B2B, B2C, or more complex B2B2C products should all be built and run in different ways.

— How does the business model relate to the IT solution?

The business model has a significant effect on the IT architecture — in both positive and negative ways. For example, you just have the idea, the product may seem very simple, but as you adjust the business model, you may realize that it needs a rather complex distributed architecture. Or, the other way around, as you analyze the business model, you may find that you can do everything from existing templates.

— What input data do you need to develop an MVP?

Business requirements, user scenarios, a general understanding of the product niche, what purpose it serves, how competitors implement similar solutions. It is also important to understand your limitations: in terms of accessible audience, data, and information flows. In short, you should figure out whether you will need a high-load system to implement the product or if a simpler solution will be enough.

— This is the best-case scenario. But how does it actually go?

Not the best-case but a normal scenario; we have come to this point through experience. It’s common for startups to have developers writing the code and adjusting the business model. But, in my experience, this often results in launching a clumsy MVP, which will need an almost complete rework involving third-party specialists.

If you change the business model, you also change the logic behind the processes running the product and essentially rewrite the code. And you’ll be lucky if you don’t need to completely change the architecture.

— What is the simplest explanation of IT architecture?

It defines the way that the system is organized, how it interacts with the external environment, its internal components, and how they interact with each other. Based on design principles, products can have monolithic or microservice architecture. The first one implies that the product is comprised of interconnected functional modules, and the second one — that interactions between these modules have more flexibility.

— How do you choose between a monolith and microservices?

It depends on product features and the specific MVP.

The advantage of monolithic architecture is quick implementation. At the same time, if you change any module, you will need to rebuild the entire service when it’s already in production. This essentially means putting the entire service on hold to build and launch a new solution. When you have a team, any module changes affect all other developers, and you need to constantly be in sync. But most importantly, monolithic architecture has limited scalability. When the system grows and becomes highly loaded, you will need more hardware resources, essentially forcing you to transfer the product to more powerful servers again and again. This leads you nowhere.

Microservice architecture is more convenient: the product consists of independent modules that interact with each other using protocols. This makes development and scaling more flexible: you only change a specific service without affecting other ones. You can also infinitely multiply and distribute them to as many servers as you like. The disadvantage of a microservice architecture is its complexity: not only do you need to work out the business logic of the product, but you also need to consider all the interconnections, select independent modules properly, and organize interaction protocols. It is always longer and more expensive.

— Sounds like it’s time to let go of monoliths…

Yes and no. Choosing architecture for MVP is tricky. A monolith is a good option if you are making a fairly simple product that doesn’t require a high-load system and/or multiple external integrations (for example, the product solves a specific problem for selected business requirements), and you need everything to be done quickly. For example, small retail mobile apps don’t need microservice architecture: it’s not worth the trouble.

But if you are creating a platform for several applications or a platform in the banking sector with many integrations, then you definitely need microservices.

How to choose an MVP configuration

— What is the most common mistake clients make during the MVP stage?

Choosing the wrong type of MVP.

— Are MVPs different?

Of course. MVP products can have several configurations. In our case, we defined three.

The first type is visual, with little or no development. It is geared towards internal customers and comes in handy when design is especially important. With this prototype, you can try out different things, analyze user scenarios, test hypotheses, and see how intuitive, accessible, and interesting the product is. This is easy prototyping for me that mostly involves UX/UI designers, analysts, and marketers.

The second option is a functional demo or a quick MVP. This is a working product but with many limitations. This option works best when you need to bring the product to market as quickly as possible, you’re confident in user scenarios and business logic, and design is not critical. This type of MVP allows the client to see their idea in practice, test the service with a limited audience (for example, 5,000 people) and limited data streams, and collect feedback. However, we always communicate that this MVP will be thrown away, and the product will be completely redesigned.

— Why? What is the point of doing it at all?

When you write code for a quick MVP, it is just a test run for the underlying business logic: you follow the ideal user flow, disregarding complex situations and possible errors. You don’t think through the situations when a user taps at the wrong place, uploads improper data, etc. This type of MVP is like a pretty storefront or a PR campaign to demonstrate the product’s functionality.

— How do you build quick MVPs?

There are numerous frameworks and off-the-shelf platforms that automate the bulk of routine functionality. This allows you to design the interface and API for your front end at a low cost. The team can use templates to quickly build the design and then wait for the connection to the server side. This doesn’t take a lot of time or effort. But this MVP option doesn’t take into account alternative scenarios: security, high load, parallel data processing.

— So, it doesn’t scale?

Non-scalable, non-failover, non-usable in a regular sense. This is a functional demo to showcase the idea or call dibs on the market. Ideally, if you have the resources, dedicate one team to building the MVP and a separate team — to developing the full-fledged product. They can work simultaneously and improve the business logic.

— There is still a third type of MVP.

Yes, the most difficult one. This is a full-fledged product with severely scaled-back functionality in the first stages.

The main thing here is to implement the key functions and the main feature, the attention-grabbing element that makes your solution stand out from the competition.

Conventionally, this is version 1.0, followed by 2.0, 3.0, etc. The functionality is expanded in a transparent way: users know how the next update will expand the product’s capabilities.

This is my favorite type of MVP: it takes longer, but you can focus on implementing the business logic as well as adjusting the product architecture and introducing a limited set of well-developed business processes on top of it.

— Why wouldn’t you make a full-fledged product then?

Time.

The market is developing very quickly these days. The competition is so strong and quick to implement new ideas that if you take a year to build, you may as well not even start.

Only large companies like banks can afford it, and even they implement this approach only for internal systems. The timeline for MVP should be measured in months. Ideally, six months if you start with an idea with business requirements.

How much does an MVP cost?

— Let’s talk about money. Many people believe that the budget for an MVP should be as low as possible: preferably under $15,000. Do you agree?

Not really. It depends again on the configuration. A version without development can be under $15,000, a functional demo — about $150,000. But at Digital Horizon, as a venture builder, we mainly build full-featured MVPs, starting at $270,000. This figure includes the system’s future operating costs.

— How so?

For example, we have a client asking us to integrate data from a certain platform so that it’s displayed into their product. They are sure that all you need to do is select 20 positions and upload them once a month.

But we look at the task in a different way — we plan everything a few steps ahead, taking into account the possibility of scaling.

When working on a fully functional MVP, we implement the system in a way that allows us to minimize future operating costs. So, in six months to a year, the product will offset its initial costs. But some clients still prefer to save money at the beginning, not thinking about what will happen next.

— On the other hand, the MVP may not take off, so you’d probably regret spending more than needed.

These are the risks. You can minimize them by building the initial MVP properly. Firstly, in terms of the business component, try to determine what functionality will bring the wow factor and implement it. If you don’t find it, you can “flip” the product and package it in a different form.

Secondly, it is important to establish clearly what will be implemented in the MVP and not give in to additional requests from the client to avoid inflating the project and going under.

Business vs. development: how to find the balance

— Okay, we’re making MVPs quickly to stay ahead of the competition. But users want everything all at once. Is it possible that stripped-back functionality will just irritate them, and you’ll receive negative feedback from the market?

It is a myth. If you come out with an interesting feature that catches users’ attention — especially in the B2C segment — people will wait. Everything will be fine. You just need to organize the development stages and establish communication with users correctly: share the date of the next release and establish what it will entail, prioritize tasks, and launch services that are most in demand first.

— So, you could release a new version every week with this approach…

You need to find a balance and monitor the frequency. If you make the updates too frequent, changes in the new version might be so insignificant (e.g., a different color) that users will not appreciate them. On the other hand, if you work on new functionality for two years, users will simply turn to competitors.

Everything is moving fast these days, so the key long-term plan in development is to maintain the vision that everything is subject to change.

This point should always be discussed with the client. It’s a bad thing when requirements are constantly changing, but it’s a good thing when there is a creative approach.

— How do you organize the development process in such conditions?

At the initial stages, we are meticulous about following the task plan: we assign the workload to each developer on a weekly basis. But as we move through the stages, the product can change, for example, if we find out that there is low demand from users for a certain feature, we know we don’t need it. Then we make changes to the following steps. As a result, our projects keep us on our toes.

— We have a contradiction here: the client wants to release the product as soon as possible and call dibs on the market, and you say that you need to find a balance between business tasks, the choice of architecture, the organization of the development process…

Development and business have one goal — to bring the product to market. But the requirements are different.

Business wants to be as fast, functional, and cheap as possible. And the task of the development team is to not make mistakes along the way — if they do, they’ll have to go back to the beginning.

That is why both parties need to closely interact and delve deep into the product. This is especially important for a venture builder. Otherwise, the company will turn into a consulting agency working based on cut and dry technical specifications. Our business is different, after all.

Speed, Creativity, Venture Builder

— What is different about development for a venture builder?

As a venture builder, you are involved in several exciting projects at once. Every product we have is a startup in the full sense of the word.

You have the freedom to choose your platform and tools, participate in discussions with the product manager and analysts to understand what you will build better. You start looking around and searching for suitable solutions right away. You can even influence the opinion of an external customer.

For example, we are currently finalizing a platform for the commercial real estate industry. It was initially based on the customer’s internal product implemented in .Net. But we suggested switching to Java because the internal system had completely different tasks than the new platform. The first was designed to store data and served a small number of users, while the second needed to serve a large number of users and have a quick return of data and practically no storage.

— Who do you have on your team?

We have developers, dev-ops to support the infrastructure. Business analysts and UX/UI designers are not part of our team, but we communicate very closely.

I’m not particularly looking for full-stack developers for my team. When we need to build products quickly, it’s better to break down the project so that the backend and frontend can work separately. The experience that a full-stack developer has is definitely a good thing. But in our case, we are looking for T-shape specialists instead.

— Who are they?

A T-shape specialist is someone who has very good expertise in one particular stack but is also improving in other “neighboring” areas. They usually understand development principles, are guided by algorithms, and they know how the system is organized.

T-shape specialists make it easier to advance projects: they can contribute to additional niches, so there will be no need for other people.

For a company, this option is a safety net in terms of resources, for developers — an opportunity to gain additional expertise and practical knowledge, without having to learn a new stack for no purpose and writing “Hello, world!”.

— Does this offer more opportunities for creativity?

Absolutely. Product development isn’t just about writing code. The developer introduces their own ideas, tests and implements them, and bears responsibility for what they create.

I like the comparison between development and iceberg layers. The client sees the beautiful top. The visible underwater part is the functional requirements from the product manager and analysts. And the hidden underwater parts are in the realm of developers.

— Do you have your own specific rules in the team?

Yes, three. The first is to be outspoken in the development process: when we design any product, each team member can participate in the decision-making process. It’s really important for me to listen to and understand my team. Collaboration makes people more engaged in the process.

The second rule is to come forward when facing problems. We work quickly, and some discrepancies are inevitable. Therefore, if you run into a problem, come to the team, describe what you don’t understand, what you see as a possible solution, and colleagues will definitely share their experience.

The third is to follow the rulebook. It might seem like you can cut corners to move quickly. But when we run several projects simultaneously, it is really important to follow the general rules.

You can write the code as you like, but when you submit it for review, you must provide the parameters, semantics, and signature that are accepted in the team.

Otherwise, you will have to explain to another developer how everything works, and this is a waste of time, speed, and money.

— Who are you looking for now?

Engineers and developers who want to be involved in product creation. Those who are ready to not only solve the tasks assigned to them but also to take responsibility for their decisions. Those who want to improve.

We have about 15 open positions. Mostly for those working with Java, but there are also positions in other specializations, for example, Python and Golang. These positions were created after we expanded our lines of business and moved into marketing, entertainment, content.

— How do you attract candidates?

These days, employers compete for developers through interesting tasks rather than salaries. And it’s not only trendy technologies that make developers interested in a project but also the product itself: they want to work on a project that will be in demand and have that “wow” factor. We try to work on these kinds of projects.

Anyway, we do also offer a good salary, medical insurance, and a nice office location. So send your CV to hr@digitalhorizon.ru, we’ll look into it.

— Do others try to hunt you as well?

Yes. There is always someone reaching out on Facebook and LinkedIn, but I ignore it. I’m interested in Digital Horizon projects and the experience I get here. For example, we are now starting to build a platform and an application for video processing. We are building an MVP — this is a hardcore startup, so we have tight deadlines and need to deliver results by almost any means. Overall, a great experience.

— What’s next? Where is development heading?

The pandemic forced various organizations to change their business models for the better. Startup development has become more stable and entered active competition with larger companies. So, there are many interesting tasks out there.

The main trend in development is related to the development tools that are rapidly moving towards business, low-code/no-code solutions, and constructors. In the past, technical aspects used to be the main focus, but today, frameworks matching the needs of end users as much as possible have gained great importance.

Technology is developing faster and faster, so you need to keep up with the flow. And I love it.

I’m a techno-optimist.