You know the post. It appears on r/startups, r/SaaS, and r/webdev roughly every 48 hours.

Someone spent two to four months building something. They launched. Product Hunt gave them a "congrats on shipping" from three other founders who also launched that day. Reddit gave them six upvotes and a question about whether there was a free tier. X gave them silence.

The title is always some version of: "I built X, got 12 visitors and 0 signups. What am I doing wrong with marketing?"

The answers are always kind. Work on your SEO. Post more on LinkedIn. Rewrite your landing page headline.

Nobody says the hard thing: the marketing is not the problem. The marketing worked. It found real people. The real people looked at the product and left. That is a product-market fit problem, and it was baked in before the first line of code was written. The only way to avoid it is to validate your startup idea before you build.

This article introduces a framework for doing exactly that, faster and more honestly than any method available before now.

What Is Vibe Research?

Vibe research is the practice of validating a product idea through AI-simulated personas before writing code, giving founders honest signal from their actual target audience in minutes rather than months.

The name is a deliberate parallel to vibe coding. If vibe coding means building software fast without a traditional engineering team, vibe research means validating fast without a traditional research team or a budget for user interviews.

Where vibe coding uses AI to collapse the cost of building, vibe research uses AI to collapse the cost of knowing whether what you are about to build is worth building.

TwinSim AI is the platform where vibe research runs. With 5,000+ culturally calibrated AI personas across India, UAE, and Southeast Asia, each built across 87 behavioral variables, TwinSim lets founders run their idea through their actual target audience before the first sprint begins.

What Vibe Coding Changed, and What It Did Not

Vibe coding collapsed the cost and time of building. A solo developer on Replit, Cursor, or Bolt can now ship something that would have required a team of four in 2021. The barrier to building is as low as it has ever been.

What did not change: whether anyone wants what gets built.

The ease of building and the desirability of what gets built have always been independent variables. Vibe coding made the first one dramatically easier. It had no effect on the second.

The psychological trap is this: when something can be built quickly, the brain reads that speed as evidence it should be built quickly. The working product feels like validation. The launch feels like the hard part.

It is not the hard part. The hard part is whether the person you built it for has a real problem, considers your solution better than what they currently do, and will pay the price you need them to pay. That question must be answered. The only variable is whether you answer it before or after you build.

Validating your startup idea before building is how you answer it before.

How to Validate a Startup Idea Before Building: 5 Steps

Here is the vibe research sequence, designed to take under an hour before you open your IDE.

Step 1: Define your actual target persona. Not "freelancers" or "small business owners." Specific: a 28-year-old freelance graphic designer in Bengaluru who invoices through WhatsApp and uses Figma daily. The more specific the persona, the more honest the signal.

Step 2: State the problem you believe they have. One sentence. "Managing client revision rounds takes her 4-6 hours per week and creates friction that costs her repeat business." If you cannot state the problem in one sentence, the build is not ready to validate yet.

Step 3: Run the persona through TwinSim AI. Ask three questions: Do they recognize this problem? What do they currently do about it? What would have to be true for them to pay for a solution? The answers will either confirm the direction or redirect it. Both outcomes are wins.

Step 4: Test your solution concept, not your product. Describe what the product does in two sentences. Ask the persona whether this solves the problem they just described. Ask what is missing. Ask what they would compare it to.

Step 5: Run it across three to five segments before deciding. The persona who has the problem most acutely is not always the persona who will pay for the solution. Testing across segments before building tells you who to build for first.

Total time: 15-30 minutes. Before any code exists.

Why Standard Validation Methods Do Not Work

Before the build begins, most founders try one of three validation approaches. All three fail in predictable ways.

The landing page with a waitlist measures curiosity, not intent. Someone clicking on something that sounds interesting is not the same as someone who will use it, pay for it, or return after the novelty wears off.

Asking friends produces answers shaped by the relationship. Friends want you to succeed. They soften concerns, emphasize positives, and avoid the comment that would be genuinely useful but socially uncomfortable. This is not dishonesty. It is how relationships work. It makes friends useless as validators.

Posting on Reddit or HN for feedback gives you opinions from people on Reddit or HN at that specific moment, who chose to read your post. They are not your actual target segment. A self-selected audience of internet-active startup followers is not a reliable proxy for the freelance designer in Pune or the small business owner in Jakarta you actually built this for.

None of these methods get honest signal from the actual person you are building for, in a context that reflects how they would genuinely encounter and evaluate your product. Vibe research does.

What It Looks Like in Practice

A developer is building a project management tool for freelance creative professionals in India. The insight: Western project management tools assume a team context. A solo-first, India-first tool priced in rupees with UPI support is a gap in the market.

Before building, she runs the concept through TwinSim AI across three segments: a freelance designer in Bengaluru with established clients, a mid-level creative at a Mumbai agency who also freelances on the side, and an early-career designer in Pune who just started freelancing.

What the simulation surfaces:

The Bengaluru designer has already solved project management with Notion, WhatsApp, and a Google Sheet. She is not looking for a new tool. Her actual pain is the client communication layer: chasing approvals, managing revision rounds, following up on feedback. A tool that solved that would displace three things she uses. A generic project management tool would displace none of them.

The Mumbai agency creative does not have a project management problem. The agency handles that. What she needs is clean separation between her agency work and her freelance work without using two devices. A different product entirely.

The Pune early-career designer is the most promising segment, but for a reason the developer had not considered. She has not settled into a workflow yet and is actively looking for one. But her price sensitivity is extreme: earning 15,000 to 25,000 rupees monthly, she will not pay more than 99 rupees for a tool unless it visibly gets her more clients or gets her paid faster.

In 30 minutes, the direction has changed entirely. The core problem (project management) is already solved for the most sophisticated segment. The real pain is client communication. The monetizable segment is the early-career designer, and the value proposition that converts her is income growth, not workflow organization.

None of this required building. The entire direction recalibrated before a single component was written.

What Vibe Research Does Not Replace

Vibe research is pre-build signal. It is not a substitute for talking to real users. Real users surface things that even well-grounded AI personas miss: the specific way someone's workflow is organized, the emotional weight of a particular frustration, the offhand comment that reframes the entire problem.

The right model: vibe research before you build, real user conversations as you build, behavioral data after you launch. Each stage answers a different question.

Vibe research also works best when you are willing to be wrong. If you are running validation hoping to confirm your idea is correct, you will interpret every result that way. The value is in the questions that do not get answered as expected. Those are the findings worth acting on.

The Cost Comparison

Three months building something nobody wants costs roughly 500 hours at a conservative 40 hours per week. Even valued at zero, the opportunity cost is 500 hours that could have been pointed at a direction with real demand.

Vibe research before building costs 30 minutes and a few dollars. The output is not certainty. It is calibration: a more informed starting point for what to build, who to build it for, and what they need it to do.

Vibe coding made building the cheapest part of starting a company. Vibe research makes the question of whether to build answerable before you start. That combination is the one that actually changes outcomes.