Do you need to build anything yet?

The decision

You have an idea, maybe a deck, maybe an agency quote sitting in your inbox. The decision is whether to spend real money building software — or whether you can get the answer you actually need without writing a line of code. It shows up before any money leaves your account, which is exactly why it matters: the most expensive way to learn that nobody wants your product is to build it. The second most expensive is to test forever while a competitor ships.

The questions that actually determine it

What would count as proof of demand — and would you accept it?

Decide the pass/fail bar before you run any test, and write it down. "At least 25 of 200 visitors leave an email." "At least 3 of 10 interviews end with a paid deposit." A test without a pre-committed bar isn't a test; it's a mood. Every ambiguous result will get rationalized into encouragement — I've done it myself, and I've watched dozens of founders do it since. If you can't name a result that would make you drop or reshape the idea, no test will help you. Neither will building.

Can the value be faked before it's built?

If a human can deliver your product's outcome by hand — matching buyers to sellers, curating a shortlist, preparing a report, making a booking — then you can sell the outcome before the software exists. That's a concierge test, and it produces the strongest signal available before a build: people paying for the thing itself. If your product's value is the automation — instant answers, thousands of users at once, real-time anything — a human can't fake it, and the cheapest doors close.

Who has already told you they'd pay — and in what form?

Rank your signals honestly. Compliments, waitlist signups, signed letters of intent, and money are four different currencies, in steeply ascending order of honesty. A compliment costs the giver nothing. An email address costs almost nothing. An LOI costs a little reputation. Money is the only signal that costs the giver what it claims to. If your strongest signal today is compliments, you are earlier than you think, and a build is premature by definition.

What does waiting cost you?

Most markets punish being wrong far more than being slow. A few punish slowness more: winner-take-most dynamics, a funded competitor already live, a platform window that's closing. Be honest about which market you're in — "someone might copy me" is not the same as "the market is being taken right now." In eighteen years of building software I've watched many products die from building the wrong thing. I can count on one hand the ones that died because a two-month test made them late.

Your options, with honest costs and risks

The conversation-only test

Fifteen to thirty problem interviews, each ending in a concrete offer: "This will cost ₹2,000 a month and starts in six weeks — do you want in?" Cost: effectively zero. Time to signal: two to four weeks. It proves the problem is real, that people recognize it in their own words, and roughly what solving it is worth. It can't prove anyone will change their behavior when the product actually arrives — talk is still talk, even honest talk. That's why each interview must end in an offer, not a compliment.

The landing page / waitlist / pre-order test

A one-page site that makes the promise, plus a little paid traffic to strangers. Cost: under ₹25,000 ($300) plus ad spend. Time to signal: two to three weeks. It proves the promise attracts people who don't know you, which interviews can't. It can't prove usage or retention, and a waitlist email is a cheap thing to give. Taking pre-orders or refundable deposits fixes most of that weakness — do it if your product allows.

The concierge MVP

You deliver the outcome manually to your first five to ten customers, with the "software" faked by you, a spreadsheet, and WhatsApp. Cost: mostly your time, plus tools under ₹10,000 a month ($120). Time to signal: four to eight weeks. It proves people will pay for the outcome and come back for it — real behavior with real money. It can't prove the economics of the automated version, and it doesn't scale. It isn't supposed to. As a bonus, you'll learn more about what the software must actually do than any spec workshop will teach you.

Building a thin real version anyway

Sometimes the signal genuinely requires working software — see the last section. Commissioned, a thin MVP runs ₹8–30 lakh ($10,000–35,000) with an Indian agency, $40,000–150,000 with a US or European one. If the product is simple and you can put in 4–10 hours a week yourself, an AI-assisted build costs ₹15,000–50,000 a month in tool subscriptions ($180–600). Time to signal: two to four months at best. The risk is plain: this is the most money and the most calendar time per unit of learning, if the same learning was available cheaper.

What I'd recommend

If you have no committed users — nobody has paid, deposited, or signed anything — the answer is no, you don't need to build yet. Pick the cheapest test that could prove you wrong, and write the pass/fail bar down before you start.

Which test: if a human can fake the value, run the concierge test — it beats a landing page because it measures behavior, not curiosity. If nobody has done more than compliment the idea, start with conversations that end in a concrete offer. If the open question is whether strangers find the promise attractive, run the landing page, and take money or deposits if you possibly can.

Build now only if one of two things is true: the demand signal you need genuinely requires working software, or your market truly punishes slowness more than wrongness. Both are real. Both are rarer than they feel at 11pm. And if you do build, build thin — the smallest thing that can produce the signal, not the product in your head.

When this doesn't apply

Three situations break the default advice, and they're worth naming precisely.

Network-effect products where the test is the product. A marketplace or social product with zero liquidity can't be faked at any scale that matters. The honest early move is one tiny geography or niche served concierge-style — and if even that can't work for your idea, you're in build-first territory with higher risk, and you should price that risk in.

Regulated domains where manual delivery is illegal. You can't concierge lending, insurance, or medical diagnosis without licenses. You can still test messaging and intent, but the build-versus-test math changes, and you need regulatory advice before you choose either path.

Deep tech, where feasibility — not demand — is the real risk. If the honest question is "can this be built at all," demand tests answer the wrong question. Build the risky core first: a technical spike, not a product.

If you're in one of these, don't run this playbook on autopilot. Get an experienced human to look at your specific case.