• Home
  • Blog
  • 5 most common mistakes founders make when developing an MVP


13.04.2021 - Read in 6 min.

5 most common mistakes founders make when developing an MVP

13.04.2021 - Read in 6 min.

It seems like everyone knows what MVP is and everyone understands that’s where they need to start at, but our experience shows that there is still lots of confusion amongst new founders that start developing their products.

Rate this post


Minimum viable product or simply an MVP. One of the most important stages when it comes to the development of a newly-founded startup. It seems like everyone knows what it is and everyone understands that’s where they need to start at, but our experience shows that there is still lots of confusion amongst new founders that start developing their products.

Today, let’s have a look at the 5 most common mistakes that we’ve encountered in more than a decade of developing software for clients from all over the world.

Mistake #1: Lack of understanding what an MVP really is

When it comes to the initial stages of designing and developing your new product, many founders seem to ignore the fact that MVP is not the only approach. We also have PoC (Proof of Concept), a prototype and only then we have an MVP.

PoC is used for either simple idea validation or, in case of a complex technical challenges, in order to test whether specific tech assumptions are executable. This way you don’t spend your money and extended time periods on ideas that are doomed to fail. Once the idea is tested, you can move to the next phases.

Now, a prototype. In most scenarios, it represents a clickable mock-up that emulates how the actual application will look and work once it’s released. The beauty of this approach is that it can be done in 7-14 days and then used to present to investors as well as end-users in order to gather their feedback and tweak the product before starting development of your MVP.

Source: InVision

To be clear, you don’t have to follow the PoC — prototype — MVP path. In your case, after you completed a PoC, it could make more sense to just skip the prototyping and go straight to MVP, likewise, in some other case, you can skip a PoC stage and start from prototyping etc. This heavily depends on what you are trying to build.

Once you identified what is that you want to build, you need to make sure that you understand that the MVP should consist of only the core features without which the app would become useless. Otherwise, you’ll get stuck in the development process for much longer than 3 months (an average time it takes to deliver an MVP), you’ll waste lots of money and effort, and most likely will eventually fail.

Mistake #2: Skipping the idea validation phase

This one I can’t stress enough. For a period of time, I worked in sales here at RST Software and I had a chance to talk to a plethora of soon-to-be startup founders. After a while, you’re getting used to hearing about ideas that, no offence, simply aren’t gonna run.

Some of them have no sensible business model, some are just another copy of another copy of Instagram, some are solving a very specific problem for a particular founder and thus probably has max 10 other people in the world who could use it. I myself had a few startup ideas that I was extremely gassed about, but thankfully, after a quick market research I realized I was the only one who’s excited.

Yes, it can be difficult to think of your own idea as a bad one, but you just need to distance yourself from it and listen to what the market has to say.

Mistake #3: Failure to identify the right audience for the MVP

Another issue with the idea validation, closely connected with the previous point, is that you may be trying to validate it in the wrong place. It could be that your initial assumption that your budget controlling software will be useful to various CFOs doesn’t represent the reality quite accurately. In the real environment, project managers could be the ones who need to be able to control the budgets on a daily basis, and they are your end-users, while the CFOs will care only about the reporting feature.

Failing to find the right audience can confuse you and make you believe that the market doesn’t want your solution, which could be simply not true. So before you jump to that conclusion, make sure you double-check whether you’ve tested it on the right audience. Sometimes, audiences should be changed twice, thrice or even more times before arriving at the exact fit.

Mistake #4: Choosing an inefficient technology stack

If you’re a non-technical founder, in most cases you’ll rely either on your team or your software development partners to pick the right technology stack. What’s worth noting is while the majority of technologies available today are capable of supporting whatever your product is aiming to achieve, the difference is that some of them are going to be an overkill in many situations.

For instance, we switched to a JavaScript-only approach a few years back because of how lightweight and easy to scale it is. And since we don’t specialize in building huge and extremely complex corporate systems but rather in the development of scalable web and mobile applications, we can solve all of our startup clients’ challenges using one core stack with a highly-specialized single-language development team.

From the founder’s perspective, it is also an incredibly comfortable approach, since they don’t need to focus on maintaining a broad tech stack, and considering JavaScript is the single most popular programming language in the world, building your own in-house team becomes so much more streamlined.

If you’ve heard that JavaScript is inferior to other languages, I recommend you to have a glance at one of my previous posts where I go through the business perspective of the 5 most common myths about JavaScript. It could give you a different point of view on the current state of the technology.

Mistake #5: The need to create a complete product

I’ve mentioned this earlier in the #1, but I’d like to dive a little deeper into the matter.

As we’ve established, it’s best to limit your MVP to a max. of 3 months of development. It gives you the agility you need in order to continuously test your idea instead of diving head-first only later to find out that it was a waste of your time and money.

How do you prioritize which features should be the core ones for the MVP and which are secondary? The easiest way to do that is to undergo a Scoping Session. You can do it yourself, or you can use external partners, like many of our clients do. The part of a Scoping Session that you are most interested in, in this particular case, are user stories.

In simple terms, those are a very detailed presentation of all the functionalities your product will consist of as well as their development time estimation. Just to give you an example, a user story can look like one of these:

  • As a user, I’d like to be able to log in with my Facebook account — 8h
  • As an admin, I’d like to be able to change the roles and permissions for external marketing agencies using my platform — 24h

Once you have it laid out like this, it becomes much easier to see what can actually be done in 480h (an average number of dev hours in 3 months). You’ll also be able to second-guess whether that Facebook login is so important. Most likely not. A regular email/password combination will work just fine for the MVP.

And to back my point ever more, how about we have a look at 17 examples of well-known companies and how their MVPs looked like? I wrote a piece on this some time ago.


As you can see, there are quite a few matters that you need to identify and work through if you don’t want to join the list of those founders who made costly mistakes that could be easily avoided when they decided to translate one of their ideas into an MVP. Obviously, those above are not the only mistakes, I’ll try to talk about more in the future, but I’m planning to dedicate the next piece to the benefits that building an MVP brings to the table. If you’re curious about that, stay tuned for the next week.

If you’re working on an MVP right now and have questions, feel free to drop me a line at ross@rst.software and I’ll do my best to help you untangle your case. Cheers!


Article notes

Rate this post


Ross Krawczyk

Ross Krawczyk

Senior Business Generalist

Senior business generalist with a mindset focused on getting things done in the shortest possible time with the best possible quality. Started his professional career in a software development company and moved up the ladder working nearly in every position available, accumulating valuable knowledge and experience related to startups development. Privately, spent his last decade understanding modern gentlemanship. Mesmerized with space industry and playing with people's minds through Sherlock-themed events filled with mind-boggling riddles.

Our website uses cookies to work correctly. Using this website with current settings means that cookies will be stored in the browser’s memory. Cookies settings can be changed in the browser’s options. For more information please visit Cookies policy.