All-around MVP [by Jobresponse]

If you're building an MVP, you don't ask how to build it.

It is always more questions than answers when approaching MVP development. By that time, you may have done some homework and read articles or even books on how to build an MVP, but still, more information is getting you even more confused. Throughout the years of experience, we've heard all types of questions and seen all kinds of projects. So let's get down to the only things you need to know about your first product development.

This note only describes the implementation part and does not consider the market, user testing, and anything that's out of the traditional product development—only experience and perspective.

How to build an MVP

This may seem like an easy question, but it is the tricky one. Building an MVP is always accompanied by a high risk of losing money and should be thoroughly reviewed before making a decision. The easy part of the question is hiring engineers to do a job for you. But what exactly should the engineers work on?

By the time engineers start writing code, all founders do their homework and, more essentially, market validation. You can not just build a product and then show it to the customers — it's too risky. But your early adopters may also want to see something upfront. As seen, one of the options is to showcase some visual product materials to the early adopters to get some feedback before building something out. In any way, you'd better somehow validate the market and get feedback. Anything light and quick could definitely be helpful. Be creative.

You do not always have to start with the product designs or come to your target audience with the ready product. Remember: to build a SaaS, you don't need MVP. You can stack something up to prove the use case — whatever it is, for with it. Some founders use just a google sheet and email to get the ball rolling. That's what you should learn to do.

It is your time to hack. Large corporations and big teams can not just ship something overnight, but you can. So put a few thoughts together about where to start hacking.

Hacking is your innovation in certain areas of business. This can be technology, operations, resource management, hiring, remote team management, outsourcing work, and intelligence.

So it depends more on those fundamental factors but not on whether you will use the outsourced dev team to get your MVP together or hire someone in-house. It is about what kind of innovations you can do in business at the moment.

When painters paint, they first get it out there as a sketch and take it from there. So it's more of a what kind of things are you going to be innovative enough to win with or without an MVP.

What makes a good MVP

A good MVP is anything that confirms a single use case. The less your MVP does, the better, but it should have one killer feature, not fifteen.

How to estimate my MVP

If you're considering outsourcing your MVP development, the question of how much that would cost comes first. You may try to reach out to the vendors, but great vendors may not be able to tell you what your project would cost and what kind of effort this may take. The best questions you can ask are whether there were similar projects and what the other projects were priced. When approaching the estimate part, most vendors start with Design Sprints or Product Discovery phase. So for a vendor to give you an exact estimate, you should engage with the vendor and start the project's initial phase. Would that work for you?

First off, before you talk to a vendor, do your homework, and get the document detailing what you're looking to do—a high-level note detailing the project and its goals. You should clearly define the project goals from the development standpoint. For example, MVP is a definition of what the product should do. It has clearly defined goals. The main goal of the MVP is a faster time-to-market. You don't want to sit around the MVP until it is perfect and then take it to the customers. If the goal of your MVP is faster time-to-market, you should cap that criterion.

The average time to build an MVP is around three months. Your MVP should be shipped no later than the third month of development. We're discussing more or less what is seen in the industry. If your project is far more complicated and is in sectors like fintech, blockchain, AI/ML, or anything that requires deep expertise and knowledge — you should account for that in your project goals. You can not just imagine shipping a blockchain application in three months. It is not how it works for this industry.

Never cap features or the budget unless you need to.

• Capping the budget — is potentially a danger zone as it does not account for the project's potential changes.
• Capping features — is potentially a danger zone as well, as opens the budget and timeline and effectively allows a vendor to work on the project until they deliver the requested features.
• Capping timeline — is your sweet spot. In this case, a vendor should deliver discussed features in a given timeline and within the budget.

If you're building MVP, capping features or budget puts you in the trap of following a single path, while you may get client feedback and now need to make corrections to your course.

Now, to make the budget assumptions look for reports stating the average rate per hour. For example, let's use the rate of $75 per hour. The development team usually includes the backend, frontend, and part-time (20%) project manager. By doing some math, you'll get the team's monthly burn rate — which is $26,400 ($75160h/m2+$75160h/m20%). 3x the monthly burn rate, and you'll get the cost of the MVP.

Same, if the vendor provides you with the team's monthly rate, 3x this number, and you'll get the estimate of your MVP.

This is a ballpark estimate and approximation. Of course, every project has something unique to account for. Moreover, if you need a UI/UX designer and QA, you should account for those roles in your estimate. Most of the time, those roles are part-time, but it highly depends on the project requirements.

Furthermore, your development journey doesn't stop once the MVP is ready. By the time your software is ready for paying customers, it is ready for improvement. All the best tech startups once started the software product and never stopped iterating on it. It is an ongoing product development, and you should account for it. By the time MVP is ready, you should have users using and paying for it; alternatively, investors funding the next phases of development.

What tech stack to use

There are as many answers as many engineers and experts are there, but we're taking an unbiased approach to equip you with knowledge.

First off, you should account for what tech stack knowledge is already on your team. Maybe a CTO on your team is familiar with some technologies. The point here, as some experts say, is that your CTO should be able to understand the technology, support it, and hire engineers with the needed skillset. But what if your CTO knows hard-core enterprise technology like Java? Would you build MVP using it? Maybe not for all MVPs that is good.

The other way to put it here is that, most likely, you will rebuild your MVP later down the line. The MVP serves to prove a single business use case. One of the most common problems is that founders keep building on top of the MVP during the later stages when there is enough funding to rebuild from scratch. Maybe not everything you're going to redo in your MVP, but the software evolves over time, and surely enough, you won't see any signs of the first product a few years into the business.

Remember: a company won't scale without the software's ability to do so. The point here is that it doesn't matter what tech stack you choose for your MVP. Anyway, you are going to rebuild it in the future. The best approach to take here is to use whatever is the closest and easiest solution.

Am I ready to outsource my MVP to a professional software team?

Software outsourcing is a skill that can be learned quite simply. Don't learn through mistakes, this lesson may cost everything. When planning to outsource your MVP, be honest — did you account for everything you need to get your product from 0 to 1?

Outsourcing MVP is commitment, and professional teams won't work with you if they spot potential risks. When planning to hire an outsourced team, ask the next questions:

• Do I have enough funding for the project's main phase? Do I have a plan for how to fund the ongoing development?
• Can I trust my vendor?

Obviously, if the answer is NO to any of the questions, don't start the project.

• You should plan your runway at least a few months ahead, so if something doesn't work out, you have some buffer to give your vendor a heads up. Never walk away without the bills paid. It isn't good.
• Trusting your vendor (in case they are trustworthy) is everything. A trusted vendor would adjust to your situation, plan ahead and do a great job for you (so you can talk to customers or investors). Some vendors can even give a time credit for you to figure out the way forward, but use the credit wisely.