How to create an MVP that is easy to maintain and scale: technical implementation

We are a digital product agency that solves client's challenges. We are against micromanagement. Those are not just words. We have proven the theory by numerous cases of our collaboration with worldwide clients. Our team consists of like-minded people who are willing to contribute to the success of each project we create. This idea not only establishes a comfortable working environment but leads to breakthroughs and innovative approaches in the way we develop products.

In this article, we want to prove the validity of such a method towards both the team and our clients. Here you will see a great example of how a creative approach saves the solution development time and investments for the product owner. It's not always obvious what features to select as the core functionality for your MVP, how they will function and interact with other parts of the product. Besides, the feedback from the first customers may be confusing. So your MVP should be easily adapted to the sudden modifications and upgrades.

Let's be honest, the way you start your MVP development defines the whole product’s success. It can be either expensive and complex, or optimal and easily scalable.

How to start MVP development: our approach

A minimum viable product (MVP) is a digital solution with the least possible functionality able to show the market its value. As it often happens with MVPs, the requirements may change within the product development stage or after getting the customer feedback. Moreover, it is not always possible to predict all the obstacles beforehand connected to the frontend or backend part of the development process, just like any other one.

Laying the solid ground for the MVP that can be easily adapted to the change requests is vitally important for the whole product lifecycle. The wrong choice in the technology stack may cause extra financial losses and the risk to completely re-write the digital solution. But we wouldn't want that to happen. Having vast experience in collaboration with startups, we have realized the potential pitfalls and decided to find a new solution that will be appropriate for such cases.

The first serious touchpoint with the challenge happened when we have received a certain inquiry from a new client. We've had to fit in the fixed project price in order to deliver an MVP that is scalable and easy to maintain. Being tied by the budget requirements we understood how it is important to build the whole development process effectively. Have you had a situation when there is a limited budget and you need to squeeze the maximum value out of it? That was the case with the Blocks project. We've realized that there are many potential risks in this journey.

The basic step required us to figure out the most appropriate solution architecture. It is a major point as product architecture transmits the business logic that may change eventually based on the market evolving conditions or the customer changing behavior. Imagine, that you invest several months and a significant amount of money on the MVP development. After launch, you realize that some part of the business logic should be modified. It reflects in the code rewriting. Sometimes a significant volume of it. It takes additional resources and time.

To prevent such results, our team members have brainstormed and tested possible solutions. That is when Porto architecture has come to our attention. After initial tests, we have started implementing it in the project.

Why Porto?

The Porto architecture helps to solve ordinary challenges that developers face within the app development process. Those techniques are not unique. They exist already and everyone can use them. But the popularity of such approaches grows depending on the current issues and the overall demand in the industry. Each solution is suitable for a certain problem.

That is how the Porto architecture appears on stage. It includes numerous methods, for instance, test-driven development (TDD) that allow to flexibly respond to the change requests from the client about the project.

TDD helps to look beyond just some framework making the whole product development process dedicated to the business needs. It is enough to cover each point with two functional end-to-end tests - positive and negative ones. This is especially important for an MVP stage when the requirements are constantly subject to change.

Basically, the Porto architecture consists of three layers

• Vendor - the framework layer;
• Ship - the application layer;
• Container - the business-logic layer.

Imagine a picture where freighters deliver containers over a sea. If there is not enough space within one ship, you can place containers on different ones. Such architecture allows you to start from a monolithic approach. If you experience certain bottlenecks that require you to expand the project resources, you can place a single container on a separate ship, dispatch it to another microservices layer and empower it with extra assets.

Your hands are not tied by a certain behavior paradigm. From the project start, you can use a certain codebase specifically for the chosen programming language. It enables you with the basic functionality that is well-tested previously and has already proven its efficiency. Even if at some point it feels hard enough to follow this type of architecture, over time you realize what a smart decision you've initially made. There is a single-principle responsibility where each part of the mechanism is responsible for handling a certain task.

Occasionally, creating integration tests allows to figure out the whole spectrum of the project requirements and saves much valuable development time. It is especially relevant when there are complex tasks within the project and you need to see the big picture. The main task here is to apply some calculations to a certain process and get the desired result.

For instance, within the Blocks project, we have worked with investments that have prices and various parameters. The goal was to evaluate the investments by certain benchmarks. For that, we have created a processing unit with a hierarchy of factors and checklists that define what influences each factor and other major matters. Each level of this hierarchy receives an estimation that eventually forms a total evaluation. Every parameter can be modified manually by the user making an impact on the final outcome. As a result, the architecture is fully typical so it is wholly configurable.

The challenge

As stated previously, the hallmark of MVP development is a high risk of potential changes in project requirements. Either the startup owner may change the final product's vision or customers’ feedback may bring unexpected results, your MVP should be easily modified upon the necessity. It so happens that when you see some intermediate result you may compare the vision you had in your mind with the tech specification description. It may not match sometimes as it is hard to reflect the blurry image in your mind with the actual result polished by the professional tech team.

That's exactly what happened with the Blocks project. At some point, we had to modify two-thirds of the initial solution architecture. Any change requires revising connections between entities. Processes and factors get changed as well. Different connections, different logic.

Here is where the Porto architecture stands out. Everything is divided into tasks and atomic actions with high cohesion and low coupling principles. It means that the connections inside of each module are firmly connected while the modules are linked weakly. If you make changes to the project, no interruptions will take place within the whole system as the connections inside of each module are encapsulated and can not be broken.

Just imagine, how much time it could take if we hadn’t thought this through in the first place. 4 days instead of possibly more than a month of code re-writing! We have saved so much valuable development time and money for the client.

Benefits of Porto Architecture for MVP development

The Porto architecture is beneficial in many ways for the MVP development. The most prominent advantages are as follows:

Other add-ons

If you need to develop a product fast and with quality, simply implement the Porto architecture, Apiato open-source framework, a couple of functional tests, statistical analysis, linters. For the record, linters validate code to make it a standard for the whole development team. It results in a clean code that is clearly understandable for any new team member. To make your product even more flexible and successful, consider implementing other technologies that are useful at the stage of MVP development and further:

These and many more tools can make your MVP safeguarded from any potential flaws and lay the foundation for easy development of the final product.

Results

From starters, the client voiced the main technical requirements to the project development like TDD and strong code review. After thorough research and initial testing, our experts have offered the Porto architecture. Its benefits were obvious and have been proven within the development phase. This choice has never been contested.

In fact, we believe this architecture can become the best foundation for any MVP development. This is a great example of how the "no micromanagement" approach contributes to innovations and effective project development.

The results are obvious and pretty compelling. Thanks to the Porto architecture offered by the team members we have managed to modify around 60% of business logic along with the project code within just 4 days after two and a half months of product development.

Just imagine, the initiative of our teammates has saved around 8x development time and money for our client! So much more to expect in the future.