No-code Prototyp experiment

Tomáš Veselý - podpořen AI
Jun 9
4 min read

We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about product development. Whether you're an inventor, a product manager, or a Chief Product Officer, using the right research methods and experiments increases your chances of building the right things for the right audience. Today we'll introduce the No-code Prototype validation method.

When to Use This Experiment?

A No-code prototype works best when the viability of a product idea — especially a software one — needs to be validated before creating production ready app. Instead of coding from scratch, a working product is assembled from existing services. It's a good fit when:

It needs to be determined whether the idea is even worth investing time, money, and development capacity in.
The value proposition can be assembled from existing tools (APIs, SaaS, no-code platforms) without writing any custom code.
Serving tens to hundreds of users is enough; scaling to thousands is a question for later.

Basic Experiment Principles

At its core, a No-code Prototypedelivers real value to real users without anything being custom-built or perfectly secured. The product is assembled from existing purchased services, connected by a script or an automation platform, while the focus stays on the hypothesis being tested.

Define the hypothesis. Determine which assumption about the product or market should be confirmed, and define what will count as success.
Select existing tools. Assemble the product from existing services. For each function, pick a ready-made service — for example Carrd or Webflow for the page, Stripe for payments, Airtable as the database.
Connect the tools. The individual services are linked using automation tools (such as n8n) or a simple script; some steps can even be done entirely by hand.
Deliver value to real users. The assembled product is put in front of genuine prospects who ideally pay for it.
Collect data. It's worth tracking acquisition (how many people sign up), activation (how many of them actually use the product), willingness to pay, and operating costs. The signal to move to the next step comes once repeat usage and willingness to pay are both confirmed, and at the same time some manual or "glue" step starts eating up a disproportionate amount of time — that's the one to replace, code, or automate first.
Identify risks. A No-code Prototype by its very nature doesn't scale and will fall apart at a larger volume of users; the manual steps also distort the picture of the real operational effort. The linked services create dependence on third-party terms, limits, and pricing. A small sample gives direction, not statistically robust certainty, and there's a risk of continuing the experiment longer than necessary to get the answer.

Real-World Experiment Example

Link to research: Ryan Hoover: Product Hunt Began as an Email List

Product Hunt, today one of the best-known places for discovering new products, started in November 2013 as nothing more than an email list. Its founder, Ryan Hoover, wanted to test whether there was interest in a daily selection of noteworthy launches, without building any platform at all.

Instead of developing a website, he reached for an off-the-shelf tool called Linkydink, which let users create shared email digests from submitted links. He had a working MVP in roughly twenty minutes. He invited a few friends from the industry to contribute product tips, and the digest started going out to subscribers every day — all without a single line of code.

Interest was confirmed quickly. Hundreds of subscribers joined in the first week, and reader behavior showed the concept worked. Only then did Hoover, together with Nathan Bashaw, code an actual website over Thanksgiving weekend. The email list didn't disappear; it connected to the website, and the two parts helped each other grow.

What Can Be Tested With This Experiment?

The main strength of a No-code Prototype is that it validates real user behavior on a working product, not just stated interest. Because the product actually delivers some value, demand, willingness to pay, and the operational feasibility of the final offering can all be tested at once:

Demand validation: whether people actually use the offering — for example a curated newsletter assembled from an email-digest tool (the Product Hunt route); the signal is the activation rate and repeat opens, not just the initial sign-up.
Willingness-to-pay validation: whether customers will really pay for the value, typically with an online course or membership area running on Webflow and Stripe; it's confirmed by a completed payment, not stated interest.
Value-proposition validation: whether this particular combination of features solves the user's problem — say, with an online store built from a ready-made template and a payment gateway; the signal is completion of the full order and feedback from satisfied customers.
Operational-feasibility validation: whether the product's promise can be fulfilled with current resources — for example a two-sided marketplace connected via Airtable, Typeform, and Zapier; it reveals which manual steps overburden the team and need to be automated.
Small-scale economics validation: whether the cost of serving a single customer makes sense against the price they're willing to pay — for example preseling a physical product through a simple landing page; it's verified before investing in scaling.
Price-level validation: which price still converts — for a paid course or subscription, the same offering is presented at two prices through Stripe; the signal is the conversion rate and revenue per visitor, not a guess.