How to launch an MVP in the no-code era

10 years ago to build an MVP you had to hire professional team and invest a lot of time and money to launch your idea. That was very difficult to do with your own or family and friends funding.

As technologies evolved, the time to build and launch an MVP was slowly decreasing from 6-12 months to 3-4 months.

Enter the no-code era

Over the past few years the situation has changed dramatically. Bubble, Softr, Webflow and other no-code and low-code tools are shaking up the industry.

An MVP today is something that can be built and launched quickly with or without little bit of custom low-code development. MVPs also got skinnier, niched down. Today founders focus on one or two features which are critical to the users. And they only build more if these initial features gain traction with real users.

They want more than ever to:

  • stay small and move fast
  • validate their hypothesis before investing too much into the product
  • fail fast if an idea does not work

This is a new generations of founders, who launch their businesses without big teams and with tiny budgets. They stay LEAN, until they find some traction and validate a hypothesis.

Given this shift, here are my thoughts on how the concept of an MVP has changed.

The new meaning of MVP

Rapid growth of no-code and low-code automation keep reducing time to launch products and the size of the team needed. These are two factors, which are changing traditional meaning of the MVP.

An MVP today is a one or two features built in 1-4 weeks. Typically using no-code, low-code and sometimes little bit of custom development. Founders make multiple MVP launches to get initial traction.

They postpone investing into full products for 3-12 months. The typical MVP team could consist of a full-time founder, who spreads the word about the product and a couple of part time, periodic roles (marketer, designer, engineer).

This approach allows founders to keep burn rates low and increase the chances of success for their products.

SaaS (or full product) is a next phase followed after MVP. It normally takes 2-3 months to launch and often includes a few intermediate launches. It might still rely on the number of no-code, low-code or simple automations, but amount of the custom development increases to improve the customer experience and product quality.

Nowadays, if you are building something and not using no-code tools or it takes several months — you’re building a SaaS, not an MVP.

How to launch an MVP in 2022

Not only the meaning, but the tools we use to launch MVPs have changed a lot. I’d like to share some of the best modern tools, which will boost your launch. Every MVP and business idea starts from launching a landing site.

Publish the landing site

It’s easy to launch landing sites today. You no longer need developers or designers. You can do it all alone. Fast. You can use the following tools to build a landing site:

  1. Buy a domain on Namecheap
  2. Move DNS to Cloudflare for speed and security
  3. Brainstorm logo & brand assets on Looka
  4. Create the landing site using Webflow templates. Setup custom domain in settings. Alternatives: Convertkit, Yep , Typedream
  5. Integrate Typeform to start collecting leads. Alternatives: Tally, Jotform
  6. Setup Google Analytics. Alternatives: Splitbee, SimpleAnalytics, Usefathom

Just focus on getting your idea out, you’ll be able to improve the design and copy later. Just get the main message right and publish it.

Most of the time, it takes 1-2 days to launch your landing site and start generating leads. With the landing site in place you can already share what you want to build and what problems your product is solving with potential customers.

Once you’ve built a landing site, the next step is to attract some people and validate your idea.

Validate your idea

There are various ways to validate your idea, but the simplest and yet most powerful is Google Ads. With a small budget you can validate your hypothesis and adjust your product direction before you invest too much.

Just write down what you want to build. You may pretend you are launching soon and even post some screenshots with design. The goal is to find out if people are really interested in what you are building, find at least few customers, before your move to the next stage. Here is great example of how to validate your idea.

Validating your idea is an essential step. It helps you test your hypothesis and make adjustments before you spent a lot of time & money to build an actual product.

Discovering your idea does not work is painful, but discovering it does not work after 3 months of full time work is even more painful.

Also, knowing the fact that many successful founders started with one idea and ended up with another adds even more incentive to validate — then build.

Build a no-code or low-code solution

By this stage you’ve already validated your idea and want to move further and build your MVP. Building custom solution might still be too risky at this stage.

It’s obvious that custom solutions take more time & money to launch. And they also increase your long term maintenance costs.

Here are tools we often use to launch MVPs quickly:

  1. Use Airtable as a database for your low-code solution
  2. Use Stripe’s pre-built checkout for fast payment solution
  3. Add Intercom to chat with leads and support customers
  4. Use Notion to manage tasks (template), track notes & roadmap
  5. Use Bubble, Softr to build your MVP
  6. Use Zapier for any kind of automations. We also like Integromat
  7. Pair no-code, low-code with tiny bits of custom development

As I’ve mentioned before, such solution should not take more than one month to build. In such a short period of time you can start onboarding real customers and charge them for your product.

An MVP used to take 3 months, but with the no-code and low-code tools you have at least a 2 month head start compared to anyone who uses the traditional approach to launch their MVP.

This could be a key factor defining if you product is successful or not.

Written by Andrew Orsich. Thanks to John McTavish and Igor Krasnik for reading drafts of this.