From Code to Cash

The MVP Is Dead: Build a Minimum Viable Audience First

August 18, 2026 · 10 min read

In short — The “build first” reflex kills the majority of solo projects before they even launch. Building a minimum viable audience (MVA) before writing a single line of code drastically reduces the risk of failure by validating real demand — not imagined demand.


You spent six weeks building your MVP. You launch it. A few “that’s cool” comments on LinkedIn, two or three GitHub stars, zero sales. You start over with another project. Same story. This isn’t a code problem — it’s a sequencing problem.

The MVP dominated startup culture for fifteen years. The idea was simple: ship fast, learn fast. Except that logic was designed for teams with cash in the bank, time to iterate, and an already-established network. For a solo operator with no marketing budget, no audience, and no safety net — the classic MVP is a coin flip played with your weeks of work.

There’s a better sequence. It’s called the MVA: Minimum Viable Audience. And it changes the order of operations in a fundamental way.

Why Most Solo MVPs Fail Before They Even Launch

The graveyard of solo MVPs is enormous. And the cause of death is almost always the same: the product was built for a problem the creator thought people had, not for a problem people were actively trying to solve.

The solo dev has a particularly dangerous bias: they can build. That’s both their strength and their trap. When you know how to code, the temptation to “just throw together a quick prototype” is constant. Two weeks become four, four become eight, and you end up with a finished product nobody was waiting for.

Data on startup failure all points in the same direction. CB Insights, in its analysis of startup post-mortems, identifies “no market need” as the number one cause of failure — cited in 42% of cases. That figure applies to teams with resources. For a solo operator, the proportion is likely even higher, because external validation is even rarer: you have no co-founder to challenge you, no investor asking uncomfortable questions, no board.

The structural problem with the solo MVP is that it optimises the wrong variable. It measures your ability to build. It doesn’t measure real demand. And in solo mode, time is your scarcest resource — far more than money.

The other trap: feedback from your circle. You show your MVP to friends, your Twitter community, fellow devs. They say “that’s cool”, “great idea”, “you should add X”. Not one of them pulls out a credit card. That feedback is noise, not signal.

The MVA: What It Actually Is (and What It Isn’t)

The Minimum Viable Audience is the smallest group of people who are targeted and engaged enough to validate that a problem exists, that they’re actively looking for a solution, and that they’re willing to pay to get it.

It’s not an email list of 10,000 subscribers. It’s not a Twitter account with 5,000 followers. It’s not a generic maker community that likes everything that goes by.

An MVA is 50 people who reply to your emails. It’s 30 freelancers who’ve described the exact same problem to you in almost identical terms. It’s a waitlist of 80 people who left their email and their phone number. Signal density is what matters, not volume.

The MVA logic flips the classic order:

  1. Identify a precise problem for a precise target
  2. Build an audience around that problem before the product
  3. Validate demand with strong signals (not likes)
  4. Build the product for that audience, with them

This reversal isn’t a marketing trick. It’s a fundamental risk reduction. When you build for an audience that already exists, you already know what they want. You no longer have to guess. And when you launch, you already have potential buyers — not people to find.

For more on the numbers behind this logic, our deep-dive solopreneur & AI statistics 2026 documents why distribution has become the solopreneur’s real competitive advantage, at a time when code has become commoditised.

How to Test Demand Without Writing a Single Line of Code

Validating without coding isn’t an option reserved for non-devs. It’s a discipline the solo dev must impose on themselves, precisely because their natural reflex is the opposite.

The pre-validation landing page. A simple page — headline, problem, solution, sign-up form — with a clear message: “This product doesn’t exist yet. If you want to be among the first to access it, leave your email.” No code, no complex back-end. A tool like Carrd or even a Notion page is enough to test. You measure the page’s conversion rate (visitors → sign-ups). Below 15–20% on a targeted audience, the message isn’t resonating. Above that, you’re onto something.

Direct conversations. This is the most underused method among devs, and the most powerful. Twenty 20-minute conversations with people in your target audience, structured according to the principles of Rob Fitzpatrick’s The Mom Test: you talk about their life, their problems — not your idea. You look for patterns. If twelve out of twenty people describe the same problem in the same words, you have a signal. If each person describes a different problem, you haven’t found the right angle yet.

Content as a probe. Publish content around the problem before building the solution. A thread, an article, a short video. You measure not the likes, but the qualitative responses: are people sharing their own experience of the problem? Are they asking “do you have a solution for that?” Those reactions are signals of active demand.

The pre-sale. The strongest signal of all. Offer something for purchase that doesn’t exist yet, at a price below the final price, with a delivery promise in X weeks. If people pull out their credit card for a product that doesn’t exist, you’ve validated demand irrefutably. Gumroad lets you do this in under an hour. Even ten pre-sales at €29 are worth infinitely more than a thousand “that’s cool” comments.

AI accelerates each of these steps. Writing a test landing page, preparing a structured conversation guide, analysing patterns in your interview notes, generating messaging variants — all of that takes a few hours with a solid workflow. What AI doesn’t replace: actually going and talking to people. The machine analyses the signal; it doesn’t create it.

The Signals That Actually Validate (Not LinkedIn’s “That’s Cool”)

You need to be brutal about this: the vast majority of feedback you’ll receive is useless for validating an idea. Not because people are being dishonest — but because saying “that’s cool” costs nothing, and people naturally avoid disappointing others.

Weak signals to ignore:

  • Likes and reactions on social media
  • “Great idea, you should do that” with no follow-through
  • “I’ll sign up when it’s available” with no email left
  • Feedback from fellow devs (they’re evaluating the code, not the market)
  • GitHub stars (they measure technical interest, not willingness to pay)

Strong signals to look for:

  • Money. Pre-sale, even symbolic. This is the ultimate signal. Someone who pays for something that doesn’t exist yet has a genuine conviction.
  • Time. Someone who agrees to a 30-minute call to talk about their problem has a real problem. Someone who replies to a long email with a long email has a real problem.
  • Spontaneous repetition. When people you didn’t reach out to come back asking where the product is at, you’ve created real anticipation.
  • Problem precision. When someone describes their problem with surgical precision — numbers, context, impact — it’s because they live with that problem every day. That’s exactly the person you should be building for.
  • Active sharing. Not a passive retweet, but someone who sends your content to a colleague saying “look, this is exactly what we were talking about.” That behaviour signals the problem is recognised across a wider network.

The practical rule: before you start coding, you need at least three strong signals. One could be a fluke. Two could be a coincidence. Three independent strong signals is validation.

Moving from MVA to Product: The Right Moment and the Right Sequence

Once the MVA is built and the signals are validated, the opposite temptation appears: keep building the audience indefinitely, out of fear of launching. That’s the “perpetual validation” syndrome. You need to know when to stop validating and start building.

The right moment to move to the product is when you can answer yes to these four questions:

  1. Can I name precisely the first 20 people who will buy? Not “freelancers in general” — specific profiles with specific problems.
  2. Do I have at least one financial signal (pre-sale, letter of intent, symbolic deposit)?
  3. Do I understand the problem better than my future users can articulate it themselves? If you can describe their pain with more precision than they can, you’re ready.
  4. Do I have a distribution channel that already works? The audience you built during the MVA phase is your launch channel. If it doesn’t exist yet, you’re not ready.

The concrete sequence for moving from MVA to product:

Weeks 1–2: the minimum scope. With your MVA audience, identify the single feature that solves the core problem. Just one. Not a complete tool — the smallest useful thing that deserves to be paid for. This is where AI accelerates massively: scaffolding, boilerplate, basic integrations — hours of work reduced to minutes. What you keep for yourself: design decisions and prioritisation.

Weeks 3–6: build with the audience, not for them. Share progress with your MVA list. Not for general feedback — for precise tests on specific features. “Does this flow make sense to you?” with a screenshot. “How much would you pay for this?” with two concrete options. This tight loop prevents scope creep and keeps the audience engaged.

The launch: MVA first, not the world. Your first launch isn’t public. It’s early access reserved for the people who followed the build. They have a sense of ownership over the product — they helped shape it. This first circle generates the first real feedback, the first testimonials, the first critical fixes. And it generates organic word of mouth, because people talk about things they’ve been part of.

After launch: the MVA loop continues. A launched product isn’t an endpoint — it’s the start of a new audience-building phase. Every satisfied user is a future ambassador. Every negative piece of feedback is information about the next angle to validate.

This sequence isn’t theoretical. It’s directly tied to the reality of the solopreneur: you don’t have the resources to correct a market mistake after six months of development. The MVA is your insurance against the most costly scenario possible — building something nobody wants.

If you want to go further on distribution as a solopreneur competitive advantage, take a look at the site audit — often, the problem isn’t the product but how it’s presented and found.


The “build first” reflex is deeply ingrained in devs. You’ll probably need to actively unlearn it, project by project. But the logic is airtight: validating the audience before the product means substituting a few weeks of conversations and content for weeks of code. The risk isn’t the same. Neither is the outcome.

Ship fast — but ship the right thing, for the right people, at the right time.


Sébastien de Bollivier has been a freelance dev since 2008 and builds solo from La Réunion. If you have a stuck project or an urgent technical question, you can find him at sebastiendebollivier.com.

Frequently asked questions

How long does it take to build an MVA before writing any code?

Between 4 and 12 weeks depending on the channel you choose. The goal isn't audience size — it's signal quality: 50 people who reply to your emails are worth more than 5,000 passive subscribers. Start coding when you have at least 3 strong signals (pre-sale, active waitlist, repeated conversations about the same problem).

Can you validate a product idea without an existing audience?

Yes. Validation without an audience runs through cold channels: posts in targeted Reddit or Discord communities, cold outreach to 20–30 specific profiles on LinkedIn, a landing page with Google Ads on a €200–300 test budget. No audience is not an excuse to code in a vacuum — it's one more reason to validate first.

What's the difference between an MVP and an MVA for a solopreneur?

An MVP (Minimum Viable Product) tests whether you can build something. An MVA (Minimum Viable Audience) tests whether anyone actually wants to pay you for it. As a solo operator, building an MVP without an MVA means burning weeks of work on an unverified hypothesis. The MVA always comes first.

Got an idea to ship? A website, a SaaS, an AI automation — built with you.

Talk about your project
Behind the scenes of the studio ✦

New products, work in progress and useful resources — the SEK studio in your inbox.