How long should it take to build an MVP?

MVP is a survey, nothing more than that

The purpose of MVP is to test waters with your initial idea. Before deciding for the users of your product what's good for them you should explicitly ask them. Thus an MVP is almost always a tool that helps in gathering feedback and users reviews.

Minimal viable product should deliver or clearly explain a single essential feature. It is ok for a functional and working MVP to be dirty if users find it usable usable. Don't aim for building anything polished, unless you can polish it within a week, not burning out yourself and your team mates.

Creating something final and ready for use is almost always a waste of your time. Chances are very high that you will not be able to achieve a final sustainable vision of a product with a single, or even second or third try. Because after you start talking to your users and gathering the feedback, things may (and will!) change dramatically, in a direction that you didn't expect.

Interactive prototype is the quickest way

MVP not necessary should be fully functional. Its goal is to demonstrate how product's most essential feature works. In other words, even an interactive and realistically looking prototype would perfectly work as an MVP. Your users don't care if it's functional or not. Because if they like it, and, more importantly, if it solves their pain points they will be ready to wait another 2–3 weeks until the first fully-functional release.

There are myriad of tools for building interactive prototypes that look like real app. Here is a bunch of the most popular of them:

• Figma
• InVision
• Zeplin
• Proto.io

They all are easy to use, and I bet any designer will find a way to create product's interactive prototype out of static wireframes using one of these tools. Once you get a clickable prototype that looks like a real product — make it public and, start conducting user interviews. You now have something to show, throw it to the users and listen to what they are saying.

Does it work with API-first SaaS products?

The prototyping approach should work there as well. But apparently in a different way. SaaS API users are usually tech savvy persons, if you show them an elegant, clear and concise interface then they are bought. Real data and optimized performance may come later, as it's usually not the goal, but rather an obvious and integral part of a product.

So, create the cleanest documentation website you can do for your product, make your SDK (if you have one) easily installable and share it with your potential customers. Let them play with it and read the docs with examples of the code. This will give a clear sense of what to expect from your product, and of course will bring you a valuable feedback. Here are some of the popular tools for creating a nice looking and helpful documentation for product's API:

• Docz
• GitBook
• Docusaurus

Iterate, and make iterations cheap

MVP is your first iteration. If the iteration is too long — you burn yourself out. Because every startup founder's motivation depends on users and their opinions. This is the most valuable fuel for your product, and you need these things as soon as possible!

On the other hand, if you spend not enough time and deliver something that looks vague, ugly and barely works but intended for production use by your customers (especially paid customers!) then you'll be overwhelmed by bad reviews. Which in turn will crash your motivation and make working on the product very hard since then. So, no matter how, impress your users and attract their attention. Building a non-functional interactive prototype is the right way to achieve the goal.