Launch Your No-Code MVP in 8 Steps

This guide describes the most relevant steps you should consider before building a no-code MVP, during the building process and after you finished your MVP experiment. It includes a brief description of each step, and I share some personal experience running MVP experiments.

Step 1 - What is the goal?

You don't just build a no-code MVP to build a no-code MVP. It's always a good idea to start with the "why". Why are we creating an MVP in the first place? What is the purpose of this MVP?

A common reason to launch an MVP is to figure out if potential users will use the product you want to build. There is a difference between people telling you that they would like to use a product and actual usage. Also, the MVP will help you to get feedback and iterate quickly. Both is helpful before you spend too much time and resources building something that people will never use. So fundamentally, an MVP is an instrument to lower the risk of the wrong allocation of resources — your teams time and energy.

We decided to start with a no-code MVP because

a) we didn't have any programmers on the team yet and

b) we were not sure if the product had the right features for our target group

c) we were wondering if we can create a retention

Step 2 - Write down a hypothesis.

You are formulating a prediction that is going to try to explain your customer's behaviour. If we offer our product or service, customers will use it in a certain way.

Your hypothesis is your assumption or educated guess, based on what you already know about your customer's problems. You assume that your MVP will solve the problem for your customers, but there is uncertainty involved.

While writing down your hypothesis, you could keep in mind that it should be testable. Your MVP is your experiment, and in the end, you should be able to tell whether it was successful or not.

In our case, we assumed that our target customers would retain monthly without having any contractual force on them. This was new to the industry. Our business model relies on recurring customers, so it was critical to test if the product features are compelling enough for our users to return every month.

Step 3 - Define KPIs to measure success.

Keep in mind that the MVP is just an experiment that will come to an end. If it is successful, you will probably have enough confidence to go all in and do whatever it takes to scale the product. It is helpful to define a threshold for each KPI before you onboard your first customer.

If you can reach the threshold for a KPI, you can mark it as successful.

Once customers start using your product or service, there will be many positive and negative emotions involved, which may distract you from making a rational decision. What teams should avoid is wishful thinking. If you can't create enough traction, your MVP might not be good enough. There are many reasons why customers don't use your MVP, and if you can't fix it, you should consider leaving it.

KPI's and the defined threshold should reflect your business model. The threshold is the minimal amount of "hitting" the KPI's that makes you go all in. So again, it is a risk-based decision. The more risk you are going to take, the lower the threshold.

For us, it was enough to see at least 15 business customers return for three months in a row. All other data regarding the business was helpful to model growth scenarios for investors but not crucial for the decision if we want to build it or not.

Step 4 - Define what is need to be built.

Our experiment goals are set. We know why we want to run it, and we know what to measure. The next step is to design a concept for the MVP. This includes a description of all the processes and workflows, whether the software or you will cover them. It's crucial to think about all the little steps that users might take and all the MVP features.

We tried to make this as lean as possible because we knew that our customer base would only be between 15-30, we were able to leave a lot of the business process logic to manual work. We labelled the entire process and categorised it into MVP automation and human support. At the end of the process, we exactly knew what we need to build with the software.

Step 5 - Choose the relevant Tools for your product.

Now that we finally know what to build, we can choose the right tools to do so. There is no perfectly fitting one set of tools to help you solve all the problems, so this might take some effort to research. The good thing is that the no-code community has grown a lot, and there is plenty of information you can easily find. The following is an overview of tools that we used to give you an example.

Webflow

We used Webflow to create the user interface. It was also used to "host" some integrations like Google Analytics, Firebase and Hotjar. All of the code snippets that need to be put somewhere were integrated into Webflow.

Webflow also offered a hosting service, a custom URL, and a lightweight data store for your website, which we used to store customer data and display in our application.

Firebase

Firebase was our user management system. Allowing us to sign up new user accounts, let the users log in, and create a user session. Firebase was connected to the Webflow Database.

Zapier

The business logic was built with Zapier. Zaps are instructions that Zapier executes based on pre-defined events. You can, e.g. let Zapier send e-Mails after the user agreed to contract.

Google Stack (Slides, Sheets, Mail and Analytics)

Slides were used as a templating tool to create personalised documents for our users. We used sheets as a cache to store information that Zapier can access execute on and google Mail was our go-to SMTP Service to communicate with our users. Analytics helped get a little bit of insight into the user's behaviour and their devices.

Hotjar

Since we only planned to serve 15-30 users, it is evident that we need an additional tracking tool that can make sense of each user session. Hotjar helped us to record user sessions.

Step 6 - Build it.

It is time to execute. You defined what you want to build and hopefully choose the right tools to build your MVP. During the building phase, it is normal to redesign some aspects of your MVP or switch tools. The good thing about the no-code MVP is that building usually takes a few days or weeks. Compared to setting up a professional software project, this is a real advantage.

Do not forget to test all features after you "finished" building. From our experience, those setups can be very fragile because you do not precisely know how some of those tools work under the hood. Debugging often is guesswork, and therefore testing is critical before launching.

Step 7 - Launch and start measuring.

Speed is your friend. Do not hesitate to launch as soon as possible. When you followed all the steps, the next logical thing to do is launch and measure. Your analytics stack will provide you with data, and don't forget to stay in touch with your customers. At this point, we assume that you figured out a go-to-market strategy for your MVP, and you will be able to attract some users. If you struggle to get traction because people do not know about your product, try to use your existing network of family, friends, coworkers, all your social accounts or consider platforms like product hunt.

Step 8 - Reflect on KPIs, talk to customers and make a decision.

Remember that the purpose of your MVP was to find out if it's worth pursuing the path of the product or service you have in mind. The last step is to get feedback and to decide whether to continue or leave it. At this point, we should differentiate between usage and willingness to use.

Imagine that your KPI's do not show the traction you expected, and you might think that your idea was terrible. This might be correct, but there could be something missing that will make your MVP a success. It is crucial to talk to your potential or existing customers and let them tell you the truth about your MVP. It might be the case that your MVP is not viable because a particular functionality is missing. At this point, you can easily step back, try to deliver it and start measuring again.

In other situations, the customer might like the idea of them using your product or service, but they only like the idea. Remember how often you started something that you thought might be cool, but you never kept doing it.

Conclusion

In the end, there is not a 100% predictable way of launching a successful product or service. There will always be many variables unknown. Using the no-code MVP approach will guarantee you exactly one thing: You will be able to launch a product or service quicker than with most other methods, and you will learn a lot about your assumptions and your customers. Remember that this approach is an experiment. After you reflected on the results, there are plenty of options for the next steps. For example, you can keep building; you can shut it down, take your learnings, and launch the next experiment.