The validation loop: find a real problem and pre-sell it before writing code

How AI in 2026 makes the old "raise then build" playbook obsolete

VC funding rewards the wrong habits and suggests the only way to start a business is with upfront capital. That's what keeps most people stuck.

The dominant story about how to start a company has barely moved in twenty years. You have an idea. You don't have money. So you spend months building a deck, chasing warm intros, polishing a pitch, and selling a vision to investors. You raise. You hire. You build for 18 months. Then — and only then — you find out whether anyone actually wanted the thing. By the time the market tells you the truth, you've burned millions of someone else's money and you answer to a board.

This is the playbook most founders absorb by osmosis, and it's the thinking that quietly kills more good ideas than any failed product ever has. It teaches you to optimise for the wrong audience (investors instead of customers), the wrong feedback (verbal interest instead of cash), and the wrong tempo (long, expensive build cycles instead of weekly tests). It also implies that if you can't raise, you can't start — which is the single most damaging lie in modern entrepreneurship.

The bootstrapped version is the opposite shape. You have an idea. You build the hackiest possible version in a weekend. You ask one real person to pay for it. If money moves from their account into your Stripe account, you have a signal worth scaling. If it doesn't, you have a much cheaper lesson, and you're free to point the next attempt at a different problem the same week.

You don't need investor money to validate most modern businesses. AI wrapper products, courses, productised services, internal tools — all of them can be pre-sold from a one-page landing site and a Stripe link before you write a line of production code. The real exception is anything that needs heavy engineering even for a proof of concept: hardware, biotech, deeptech. Everything else, if you can't convince one human to move money to your Stripe account, you don't have a business worth funding either — you just have an idea that hasn't met the market yet.

What's changed in the last two years is the cost floor of actually shipping a V1. AI coding tools mean a solo founder can now build a real working MVP — not a clickable prototype or a Figma mockup, but a deployed product with auth, a database, payments, and the core feature set — in the same weekend it used to take to write the pitch deck. App products that legitimately needed an engineering team and a seed round three years ago are now built end-to-end by one person before any investor conversation. You can own the entire product design, build, delivery, and testing loop yourself, and only entertain a capital conversation (if ever) once the product is already earning.

And the size of the transfer barely matters. A $5 monthly subscription. A $20 one-off. A tiny early-bird deposit. The signal isn't the dollar amount — it's that a stranger reached for their card and entered the details for something you described. That act is the only honest vote of confidence the market gives you. It's the difference between an idea that's desirable and one that's merely polite-interest-worthy. Once that's happening, you can think about pricing, packaging, scaling, even raising. Before it's happening, no amount of polish or planning changes the underlying problem.

The alternative: prove demand with one paying stranger before you build

The validation loop is what you do instead. Not "do investors believe the deck." Not "do friends say it's a cool idea." Just: did money — any amount, from a real stranger — move into your account, before you built the thing. Scaling, systems, hires, and (much later) outside capital all come after that signal. Never before it.

The single biggest predictor of whether a side business survives the first year is not the quality of the product, the polish of the brand, or the budget behind the launch. It's whether the problem you picked is one your target buyer was already paying (in money, time, or frustration) to solve. Everything downstream of that is execution. Everything upstream of that is wishful thinking.

I've learned this the slow way, more than once. The businesses of mine that took off all started with a real, expensive problem and a small first answer. The ones that struggled were the ones where I was in love with the idea and only loosely paying attention to whether anyone else cared. The validation loop is the discipline that protects you from your own enthusiasm — and from the entire VC-shaped script that says you need permission and capital before you're allowed to start.

The six steps from idea to first paying customer

Here's the shape, then we'll go through each one.

1. Run 5 to 10 user interviews. Real conversations with real people who have the problem.
2. Extract the job-to-be-done. Compress what you heard into a single statement of what the buyer is actually trying to accomplish.
3. Synthesise the patterns. Pull the signal out of the transcripts. What do people keep saying?
4. Design a cheap experiment. Build the smallest test that produces a clear yes or no.
5. Pre-sell the offer. Take real money before you've built anything.
6. Stress-test against your harshest critic. What would the smartest skeptic say? Answer them honestly.

Step 1: Run 5 to 10 user interviews

This is the step most people skip, and the one that decides everything else. You cannot validate an idea by thinking harder about it from your desk. You have to talk to people who have the problem, in their words, before you formalise anything.

The mechanics are simple. Sketch a rough hypothesis of who has the problem (industry, role, life stage, budget) — just enough to know who to email. Make a list of 20 people who roughly fit. Send a short, polite, specific message asking for a 20-minute call. Aim for 5 to 10 calls in the next two weeks. Record them (with permission). Stay quiet. Let the person talk about their actual workflow, what they've tried, what didn't work, what they wish existed.

Before you send the first calendar invite, sketch the script. The interview guide skill turns your fuzzy "I want to learn about X" into a proper behaviour-based discovery script — past-tense questions about what they actually did, not leading questions about what they think they'd want. The difference between a good interview and a useless one is almost entirely in the questions. Use this once and you stop asking "would you pay for this?" (which gets you polite lies) and start asking "the last time you ran into this problem, walk me through exactly what you did" (which gets you the truth).

Once you have transcripts, the user interview analyzer skill does the heavy lifting on extracting themes. You feed it the call transcripts and it pulls out the recurring pain points, the language people use, the workarounds they've built, and the moments where they tried something and gave up. That output is gold. It tells you exactly what the buyer thinks they want and (more usefully) what they actually need.

For the persona work itself, the persona generator skill turns the patterns from your interviews into a tight one-page profile of who you're selling to. Not the marketer's fake persona ('Marketing Mary, 34, drinks lattes'), but a useful working description of their workflow, their budget, their decision triggers, and their objections.

Step 2: Extract the job-to-be-done

Now that you've heard a dozen people describe the problem in their own words, compress what you heard into a single jobs-to-be-done statement. Features lie. Jobs don't. A parent who pays for tutoring isn't buying lessons — they're buying their kid getting into a better university and the peace of mind that comes with it. A small business owner who pays for a CRM isn't buying contact management — they're buying the absence of dropped follow-ups that have cost them deals. The interviews give you the raw material. The JTBD statement turns it into a brief everything else flows from.

The JTBD extractor skill takes your interview notes (or transcripts, or even a rough summary of what people kept saying) and produces a proper jobs-to-be-done statement. It captures the situation, the desired outcome, and the emotional layer underneath. That statement becomes the brief for everything downstream: the wider synthesis, the offer you write, the landing page you build, the pre-sell message — all of them reference back to it.

Step 3: Synthesise the patterns

The JTBD statement gives you the core job. Wider synthesis gives you the structure around it: which sub-problems show up most, what language people actually use, what workarounds they've already tried, what they'd pay to make go away. That structure is what turns the pile of interview notes into an actual build-or-pivot decision. The thing you're looking for is a small number of shared problems described in shared language by independent people. That consistency is the signal.

The research synthesis engine skill takes your full set of interviews (plus any survey data, Reddit threads, or competitor reviews you've collected) and produces a structured synthesis: what's the top three problems, how often does each appear, what's the language people use, what are the current workarounds, what's the size of the prize. That's the document you make the build-or-pivot decision against.

Once you have the patterns, you can also map them out visually using the opportunity solution tree skill. The tree forces you to be honest about the gap between 'big outcome the buyer wants' and 'specific thing you could build'. Most ideas die on this tree, because you realise the solution you had in mind doesn't actually move the outcome the buyer cares about. Better to find that out on a piece of paper than after three months of building.

Step 4: Design a cheap experiment

Once you have a synthesised picture of the problem, the next move is the smallest test that will produce a clear answer. Not a polished product. Not a fully designed offer. An experiment.

Before you design the test, name the bets. The assumption audit skill walks you through your idea and surfaces every load-bearing assumption underneath it — that buyers care about this specific outcome, that they'll pay X, that they can find you through Y channel, that the workaround they have today is actually painful enough to switch. Each assumption gets a risk rating and a cheap test you could run this week. The point isn't to test all of them. It's to know which one would sink the business if you got it wrong, and test that one first.

The experiment designer skill then takes the riskiest assumption and produces a one-page test plan: what you're testing, how you'll measure it, what success looks like, what failure looks like, how long it'll run. The discipline of writing this down before you start is what separates 'I tried a thing' from 'I learned something'.

Common cheap experiments include: a landing page with an email signup and a clear offer ('first 20 spots, $99, ships in 30 days'), a Google Doc proposal sent to 10 prospects, a paid pilot with three friendly customers at a discounted rate, or a one-page Notion site with a Stripe checkout. The goal is the same in every case: get a yes or a no from real people in a defined window, without building the actual product.

For the landing page itself, the AI website cloning skill lets you describe the look and tone of an existing site you admire, and produces a clean version of your own page in an afternoon. The page doesn't need to be perfect. It needs to be clear: who it's for, what they get, what it costs, and how to say yes.

Once the shell is up, the UX copy review skill sharpens the words on it — headline, subhead, button label, the three lines under the price. The shell wins eyeballs. The copy wins clicks. Most early landing pages lose the sale at the headline because it describes what the product is, not what the buyer gets. This skill rewrites the page line by line and tells you why each change was made, so you learn the pattern.

Step 5: Pre-sell the offer

This is the step that produces the only feedback you can fully trust: money moving from a real person's account into your Stripe account, for a thing that doesn't exist yet. Anything short of that — verbal interest, a "definitely send me the link", an investor's nod — is encouragement, not validation. The Stripe notification is the line. Don't start scaling, hiring, or building production systems before you've crossed it.

The mechanics of pre-selling are smaller than people expect. A one-page description of what they're buying. A clear delivery date (and a clean refund policy if you miss it). A Stripe link. Then you take the people you've been talking to, the ones who said the problem was real, and you offer them the chance to be the first customers. 'I'm building this for delivery in 30 days. The first 10 spots are early-bird pricing, it'll roughly double after. Would you like one?'

The one-page description is the offer itself, and it deserves more thought than most founders give it. The product brief writer skill takes your JTBD statement, your interview findings, and your draft offer, and shapes them into the tight one-page document a stranger can read in 90 seconds and either reach for their card or close the tab. It forces clarity on the four things every buyer needs to see: the outcome they get, the steps to get it, what makes you credible to deliver it, and what it costs. Vague offers don't pre-sell — specific ones do.

The asks that work tend to be specific, time-bounded, and small. Specific: 'this delivers X by date Y for price Z'. Time-bounded: 'first 10 spots' or 'closes Friday'. Small: not the full vision, just the first useful slice. A scrappy paid pilot is far more useful than a polished enterprise pitch at this stage — the goal is to get the Stripe ping, not to look impressive.

To find more potential buyers for the pre-sell, the signal-based LinkedIn outreach skill is the one I lean on most. Instead of cold-blasting hundreds of generic messages, it finds people who have given off a recent signal that they care about the problem (commented on a post, joined a community, attended an event), and helps you write a personalised note that references the signal. Reply rates run 15 to 20 percent, which is more than enough to fill a small pre-sell window.

Step 6: Stress-test against your harshest critic

The last step before you commit is the one most founders skip out of self-protection. You take the strongest version of the case against your own idea and answer it honestly.

The devil's advocate skill is designed for this exact moment. You feed it your idea, your validation evidence, and your plan, and it produces the case a smart skeptic would make against you: where the market analysis is thin, where the pricing assumption is shaky, where the buyer might be saying yes for the wrong reason, where the competitor moat is stronger than you think. The point is not to talk yourself out of the idea. It's to know exactly where it's fragile so you can either reinforce those spots or knowingly proceed with eyes open.

If you can answer the devil's advocate honestly and still believe the build is worth doing, you have something. Most ideas don't make it to this step. The ones that do tend to be the ones that turn into real businesses.

Flow vs. force: how to tell if the market is pulling or you're pushing

One pattern I've noticed across every business I've started: the ones that worked had a feeling of flow from the first week. Replies came back. Conversations were easy. People volunteered information without being asked. The pre-sell asks landed. Flow looks like a Stripe notification buzzing on your phone the same evening you sent the link — even if it's a $5 subscription, even if it's a tiny early-bird deposit. Force looks like 'sounds interesting, send me a deck' and then silence. The ones that didn't work felt like dragging a boulder. Reply rates were low. Conversations were polite but flat. The pre-sell asks were met with 'sounds interesting, let me think about it'.

The difference is not effort. I worked just as hard on the businesses that didn't take off. The difference is the market. When the problem is real and the buyer is the right one, the whole loop has a slight tailwind. When the problem isn't real enough, no amount of optimization makes it click.

If you find yourself in the second category after running the loop properly, take it as redirection, not failure. The market just told you the problem isn't where you thought it was. Keep the systems you built. Keep the skills you sharpened. Point the next idea at a different problem. The second loop is faster than the first. The third is faster again.

A realistic 14-day calendar you can run alongside a day job

Here's how a tight version of the loop fits into two weeks alongside a day job:

Two weeks. One decision. Either way, you've learned more about the market than three months of pure thinking would have taught you.

Next in the series: building the operational stack once money has moved

The validation loop tells you whether to build. The next article in the series is the one about how to actually build the operational stack once you've decided to ship: the CRM, the payment flow, the email sequences, the landing page, the lead-gen pipeline. All of it cheaper to own than to rent, all of it sharing the same database, all of it in one folder on your laptop.

Skills referenced in this article

Every AI skill linked above, in one table you can bookmark.