No-code, prototype, or real code for your first test

The decision

Your early signals justify putting something in users' hands. The next cheque you write depends on the format: a clickable prototype, a no-code build, or real code. Choosing wrong costs you in one of two ways — months and lakhs spent on software you'll throw away, or a toy that can't answer the question you were actually asking. This is not a taste decision. The format is picked by the question you need answered.

The questions that actually determine it

What question is this version supposed to answer?

This is most of the decision, so start here. "Do people understand and want this?" is answerable with a clickable prototype in a week. "Will they come back every week?" or "will they pay?" can only be answered by something that works — nobody forms a habit around a Figma file. Write your question down in one sentence. If you can't, you're not ready to pick a format; you're still in demand-testing territory.

Does the core value depend on something no-code can't do?

No-code tools are genuinely good at forms, lists, dashboards, marketplaces, and workflow apps. They hit a ceiling fast on heavy custom logic, real-time behavior, unusual integrations, and anything performance-sensitive. If your product's core magic lives past that ceiling, a no-code version will demo the shell and not the magic — and your test result will be a verdict on the shell.

Who will build and change it — you, or someone you pay?

This is the part most founders miss. No-code's real advantage isn't that it's cheaper to build. It's that you can change it on a Tuesday night after three customer calls, without raising a ticket. That advantage evaporates entirely if an agency owns the Bubble app: you get all of no-code's ceilings plus all of a vendor relationship's latency. If someone you pay will make every change either way, the case for no-code shrinks to a modest price gap.

If the test succeeds, what happens to this version?

Plan the funeral on day one. A successful no-code test usually gets rebuilt in real code, and the rebuild costs 60–100% of what a direct real-code build would have cost. That sounds like an argument against no-code. It isn't — see the recommendation below — but it belongs in your spreadsheet from the start, not discovered later in a tense conversation about platform pricing.

Your options, with honest costs and risks

The clickable prototype (Figma or similar)

Screens wired together so a user can tap through the flow. Nothing works; everything is visible. Commissioned: ₹40,000–2 lakh ($500–2,500). Do it yourself: near-free. Timeline: one to three weeks. It proves comprehension and desirability — do people get it, does it pull. The ceiling arrives immediately after: it cannot tell you anything about usage, retention, or payment, and mistaking prototype enthusiasm for demand is a classic way to fund a build the market never asked for.

The no-code / low-code build (Bubble, Glide, Airtable-glue)

A working product without engineers. Built yourself: ₹50,000–1 lakh a year in tool fees ($600–1,200). Commissioned: ₹1.5–4 lakh ($1,800–5,000). Platform fees run $30–500 a month and rise with usage. Timeline: two to eight weeks. It proves real usage and real payment. Three ceilings to respect: technical (custom logic, performance), financial (per-user platform pricing that climbs exactly when you succeed), and structural — your product lives on someone else's platform, on someone else's terms.

The AI-assisted thin build (founder + AI tools, real code, tiny scope)

New in the last few years and now a legitimate middle path for simple products: you, AI coding tools, and a ruthlessly small scope. Cost: ₹15,000–50,000 a month in tool subscriptions ($180–600), plus 4–10 hours a week of your own time. Timeline: four to ten weeks, depending on those hours. It proves the same things a no-code build proves, in real code you own, with no platform ceiling. Its ceiling is you: anything beyond simple screens-forms-and-flows, anything security-sensitive, and the honest question of whether the weekly hours exist. Budget for a professional review before the code carries real customer load.

The commissioned thin build (freelancer or agency, real code)

A senior freelancer runs ₹1.5–3 lakh a month ($1,800–3,600) in India, $4,000–10,000 a month globally. An agency MVP runs ₹8–30 lakh ($10,000–35,000) in India, $40,000–150,000 in the US or Europe. Timeline: two to four months. No format ceiling — it can eventually answer anything the product can answer. Its real ceilings are your bank balance and your iteration speed: every change goes through someone you pay, which is a bad property in exactly the phase when you should be changing things weekly.

What I'd recommend

Let the question pick the format. If the question is "do they get it," make a prototype and spend nothing else this month. If the question is "will they use it weekly" or "will they pay," you need something usable.

For the most common reader — non-technical, some budget, an unanswered retention question — my default is a no-code build that you construct and operate yourself, even if learning the tool costs you a slow month. The editability is the point. If the product is simple and you can genuinely commit 4–10 hours a week, the AI-assisted thin build is the stronger version of the same move: the same editability, real code you own, no platform rent.

On paying twice: do the arithmetic before you flinch. Say a direct real-code build would cost ₹20 lakh ($24,000). The no-code path costs ₹2–4 lakh to find out the truth, plus a ₹12–20 lakh rebuild only if the test succeeds. The real-code-first path costs the full ₹20 lakh before you know anything — and I ran a SaaS company for five years, so take it from me that version one rarely survives contact with paying users intact. Paying twice for a winner is cheaper than paying once for the wrong product.

Go straight to a commissioned real-code build only if the core value sits past the no-code ceiling and the AI-assisted path is out of reach — and then buy the thinnest version an honest builder will quote you.

When this doesn't apply

Compliance or performance rules out no-code from day one. Health records, payments infrastructure, anything real-time or latency-critical: the platforms can't legally or technically carry the core, so the choice collapses to prototype versus real code.

Hardware and deep tech. The first risk is feasibility, not format. Prototype the physical or scientific core first; this software-format decision comes later.

A technical co-founder is already building. Then this decision belongs to the two of you together, and the format should follow their skills and speed — a strong engineer shipping real code in weeks beats any no-code plan on paper.

If you're in one of these, don't force the default. Get an experienced human to look at your specific case.