In our article about clients’ first Minimum Viable Product meeting, we have tried to present the value of having a well-defined vision and plan for MVP conversations. We have mentioned how working with an external software house differs from being in charge of your own team and is, therefore, worth preparing for, even before your first meeting takes place. We have brought up the significance of effective communication between business owners and software houses and commented on why clearly stating your expectations is always better than making assumptions. We have also mentioned how passion and belief in your vision can be a deciding factor in MVP conversations – not unlike financial matters, as a clear custom quote is often quintessential from the word go during those meetings.
How to Bring Your MVP Project to Life Successfully?
In our article about clients’ first Minimum Viable Product meeting, we have tried to present the value of having a well-defined vision and plan for MVP conversations. We have mentioned how working with an external software house differs from being in charge of your own team and is, therefore, worth preparing for, even before your first meeting takes place. We have brought up the significance of effective communication between business owners and software houses and commented on why clearly stating your expectations is always better than making assumptions. We have also mentioned how passion and belief in your vision can be a deciding factor in MVP conversations – not unlike financial matters, as a clear custom quote is often quintessential from the word go during those meetings.
After establishing a clear goal and a clean-cut roadmap which can get you to it, you can start actually building your product. As with most things in life, there are multiple ways you can go about doing it. Each of them comes with many decisions that need to be made, as well as several traps you can fall into and should therefore avoid; success in doing so is strictly related to the choices you make. This is why we have devised this article – to help you make the right ones.
First question: where to start MVP development? Which parts and functionalities should you focus on?
By the time you approach a software house with your idea, you probably have a rather extensive list of your product’s features; of course, as the name suggests, it should be a minimum product, but there are still multiple potential entry points we can look into. There are two main possible ways you can go about making your first choice:
1. Starting from the functionality imposing the biggest risk, from the biggest unknown quantity. This could for example be some complex algorithm or connection to some crucial external API. Why? Well, if something bad is to happen with those, you really want to know about it early, as mistakes made at this stage of the project can impinge on the outcome of the whole operation. There may be a need for building some kind of proof of concept or a prototype, but you should not build upon it later; you also ought to use it in a properly architected application later on.
2. Starting from the functionality which brings the highest value to the client. With this solution, you should focus on the most important functionalities. It works best in SaaS (Software as a Service) models; think about functionalities that the user will come for and is willing to pay for. Those are the ones you want to put the biggest emphasis on; you do not want to start with unimportant functionalities and be left without crucial ones.
There are also things you should avoid when you are just starting to develop your product. They are usually not essential during this stage of development, and your energy can be better spent elsewhere:
1. Do not focus on an administrative panel. Try managing your settings in config files in the first phase if that is possible. It may save you both time and money, as allocating your resources wisely is critical during the early stages of developing your product.
2. If you want to offer only free services in the first phase, you may consider postponing the development of your payment or subscription mechanism. This may also be a good move if you are yet unsure about the specifics of your business model, as you avoid the risk of confusing the customer with inconsistent financial terms and conditions.
3. If you are building a web application, you may find that you do not need a full mobile app right from the get-go. This should not apply to your website, though; you need to make sure that it is operational and responsive to the fullest extent. You may also consider a Progressive Web App solution, as they do not require to be separately built or distributed, allowing you to save some time and money. They try to combine the advantages of native apps and websites, making your product more appealing for the customer, thanks to being more accessible while remaining highly functional.
There are two main things you should think about while constructing the plan for your first MVP: iterative and incremental development.
Iterative development
It is a short, repeatable process with regular retrospectives on how well we have been doing so far and whether we are on the right track to achieve our goal. It is perhaps the most important part of healthy development, as it helps us make sure we are doing the things we have set out to do; it breaks down the process of developing a big application into smaller parts which are easier to manage. The feature code is developed and tested in repeated cycles or iterations; new functionalities can be built and tested with every iteration until the application is ready to be presented to end users. Additionally, thanks to retrospective meeting after each cycle, we can improve our process as we go.
Incremental development
It is predicated upon the concept of Mayo-Smith pyramid. At its core, it states that the outcome of large software projects depends on factors that are beyond the development team’s control. These factors sometimes render advanced, detailed planning impractical. Large software projects usually involve many functional components; it is, therefore, best to finish the ones we are working on – this would include finishing designing, coding and debugging them – before starting to develop the next ones. This approach is called Complete Before Continuing. It may be compelling for several reasons: the entire team is involved in working on the project at the same time – not just programmers and testers, but also designers, information architects and people in charge of business development. All of them receive valuable feedback early in the development process because testing can begin almost immediately after conceptualising a specific functionality. This means that they all work on it together, without anyone getting too far ahead of other parts of the team. Also, as it allows for having functional and (hopefully) defect-free versions of the application prior to scheduled completion dates, the team is more likely to respond better to any schedule or scope changes. It is a methodology emphasising cooperation and mutual understanding.
You should not, therefore, spend months mulling over a single feature, as it does not really help anyone involved; a better approach is to build your whole product as soon as possible and polish any potential deficiencies later on.
Technology choices
There is a variety of technologies available to people working in web development right now. Each of them has its pros and cons, so having a good technology partner can be very helpful in choosing the best ones for your needs. Good technology choices can be very beneficial in improving workflow and efficiency; bad ones, however, have a high likelihood of slowing you down.
Some frameworks are considered to be better than others in building MVPs; two of the main ones are Laravel and Ruby on Rails. They have gathered a big and enthusiastic community around themselves, mainly due to their ease of access and stability. This second quality is something worth spending your time considering; it is usually better to choose a stable and reliable framework over a more ‘hype’ one unless it offers some distinct advantages. Also, there is rarely a need to reinvent the wheel – try to implement as many ready-made solutions as possible. They can speed up the development process significantly and make your product more trustworthy. On that note, you should consider using as much open-source technology as possible. Even if you do not care about its greatest advantage, which is the fact that it is free to use, there are many other reasons why it is so popular. It is very secure, as the code is accessible to everyone, which means that anyone can fix potential bugs as they are found. It is not dependent on whoever created it, as it is continuously being developed by its users with the use of open standards available to all of them.
Something else you might want to do is to use cloud solutions. These are a safe and very scalable way to go when designing MVPs; current cloud platforms have ready-made blocks that can help you build your application. They come with specific price tags, of course, but they are usually well worth the money. They allow you to produce your application or website much faster, as you do not need to build everything from the ground up; this can save you a lot of time which would otherwise be spent on development. Cloud solutions can get your product to market much faster, so you can validate your idea – and, consequently, have paying customers – sooner. Most of the tools are utilized per use; this means that you pay for them only when you use the platform. Therefore, using them means that you have paying customers. Additionally, most of the major cloud providers offer free tiers to help you start out. It is important to think through your pricing model while building a SaaS solution in order to accommodate the cloud cost correctly – also including a free plan.
Architecture choices
When it comes to choosing your product’s architecture, it is worth keeping it as simple as possible and building just as much as you need – more code means more maintenance. On the other hand, you need to be prepared for future changes, so making your code somewhat flexible is usually necessary. Built-in flexibility comes at a cost, however, so communicate with your team on what can change as time goes by; there really is no need for it everywhere.
You should correctly discover and build boundaries within contexts in your application in order to create proper logical modules, though using microservices to split those physically should not be needed.
Remember that errors or poor decisions made in the design phase have the biggest impact on the final cost of the product, so trying to make as few of them as possible is well worth the effort.
It is usually best to postpone technical decisions at this stage of the operation if possible. You will be equipped with more data further into the project, so you should be wiser when it comes to making conscious decisions.
Another important thing is to properly document your actions. If it turns out that you need an additional workforce to help you in the future, this will make it a lot easier for new people to join your project. There are a few things which can help you achieve this: having installation scripts or docking containers, a proper architecture diagram or an Architecture Decision Record. An ADR is a document in which you should write down important architecture decisions you have made along the way – what sort of problems did you encounter, which options for resolving those problems were available to you, and what reasons did you have for opting for the particular solutions that you chose.
Summary
There are many different ways to breathe life into your MVP project and make it a reality, all of which have their pros and cons. You should, however, be aware of the fact that you can find some common points between them.
The first thing to remember is the simple fact that in order to go fast, you need to do things well. There is no point in rushing anything if the results are to be subpar. On the other hand, perfection is not your friend at this stage of development; it is much better for your project to be done (and already in use) than stuck in the planning phase because you cannot let imperfections go – and there are bound to be some when you are just starting out. This does not mean that you should not think big and strive to make your product as good as possible, but you should be focused on what is at hand and on what needs to be done to get your project going. Another thing whose significance cannot be overstated is proper communication. Talking to your team should become one of your focal points – it makes everybody’s work more efficient, helps to avoid misunderstandings and alleviate stress among the members of the team, not to mention boosting their morale. An invested leader translates into a determined team, and that, in turn, makes your product much more likely to succeed.
On-demand webinar: Moving Forward From Legacy Systems
We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.
Latest blog posts
Ready to talk about your project?
Tell us more
Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!
Strategic Planning
We go through recommended tools, technologies and frameworks that best fit the challenges you face.
Workshop Kickoff
Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.