Skip to main content
Start with a project

Post-MVP validation loop

Validate the SaaS idea you actually built—not the pitch in your head.

Bring the landing page, demo, repository, deck, waitlist, or rough product. Identify the assumption most likely to make the current product irrelevant, run one approved test, and let behavior change the next decision.

Start with a projectSee the workflow

Qualification boundary

Separate four assumptions that founders often mix together.

A product can pass one assumption and fail another. Diagnose the current risk before choosing a test.

Use this workflow when
  • Problem: the target customer experiences the pain frequently and with meaningful consequence.
  • Audience: you can identify and reach people who share that problem and trigger.
  • Solution: the current workflow helps them make progress better than the workaround.
  • Exchange: they will provide time, access, behavior change, or money for the result.
Do not count this as proof
  • A one-shot AI idea score presented as proof of demand.
  • A broad market-size statistic without evidence that your reachable customer will act.
  • Compliments from people who cannot or will not use the product.
  • Another feature sprint without a stated assumption or acceptance test.

Smallest complete workflow

Move from artifact to one falsifiable test.

Validation is a sequence of decisions, not a certificate. Each cycle should make the next investment easier to justify—or easier to stop.

  1. 01

    Inspect the current artifact

    Describe what the product does now, who it addresses, the promised progress, the first value event, and the action a visitor is asked to take.

  2. 02

    List assumptions as testable statements

    Write problem, audience, solution, and exchange assumptions so each could be contradicted by observable evidence.

  3. 03

    Choose the riskiest assumption

    Select the assumption that is both uncertain and capable of making the next build cycle wasteful. Explain why it outranks the others.

  4. 04

    Research the decision context

    Use source-linked research to find current alternatives, customer language, communities, triggers, and contradictory evidence. Treat it as context, not demand proof.

  5. 05

    Design the smallest real test

    Ask qualified people to take an action: try the workflow, share data, schedule a follow-up, return, refer someone, or pay. Define the threshold and stop condition first.

  6. 06

    Approve and run the bounded action

    Review the exact target, payload, channel, cost, and acceptance criteria. Keep public posts, direct messages, email, code changes, and deployments inside their real approval paths.

  7. 07

    Choose continue, revise, or stop

    Continue when the behavior supports the assumption; revise when the audience or workflow is close but wrong; stop when the core problem, access, or exchange is absent.

Inspectable control

Example approval card — riskiest-assumption test

This is an illustrative task card, not a claimed customer result or completed experiment.

Objective
Test whether the current landing-page promise matches a recurring problem for solo SaaS founders who already shipped a product.
Action
Run approved research on ten current public problem statements, then prepare a five-person conversation batch for separate review.
Target
English-speaking solo SaaS founders with a live URL and recent evidence of a post-launch demand problem.
Acceptance
Return source URLs, exact problem language, counterevidence, five qualified targets, and a proposed test. Do not treat research frequency as proof of willingness to use or pay.
Stop condition
Stop if fewer than three sources match the defined audience and trigger, or if the evidence points to a different problem than the landing page promises.
ReviseRejectApprove exact scope

Validation handoff template

Make the artifact-to-decision chain inspectable.

Complete this handoff with observed evidence from the actual product and test. Empty or contradictory fields are useful; invented certainty is not.

Input artifact
Link the exact URL, repo snapshot, deck, demo, or landing-page version reviewed.
Riskiest assumption
State one falsifiable problem, audience, solution, or exchange assumption.
Why this risk
Explain why being wrong would invalidate or redirect the next build cycle.
Approved test
Record the target, action, payload, channel, cost, acceptance threshold, and stop condition.
Returned evidence
Separate observed behavior, direct statements, no-response, failures, counterevidence, and remaining unknowns.
Decision
Choose continue, revise, or stop; name the evidence behind the choice and the next permitted action.

Decision scorecard

Use a validation ladder, not one blended score.

Evidence gets stronger as the customer gives up more time, access, habit, reputation, or money.

01

Context

Credible sources establish the category, alternatives, and language.

02

Problem evidence

Qualified people describe frequency, consequence, and a current workaround.

03

Commitment

They give time, data, access, a referral, or agree to a next step.

04

First value

They complete the target workflow and experience the intended progress.

05

Return

They repeat the behavior after the first assisted attempt.

06

Payment

They pay to continue receiving the value.

Current product boundary

Plan with what actually runs today.

No research report or automated evaluator can validate demand by itself. Validation remains specific to the audience, product state, offer, channel, and evidence collected in the test.

Research

Live

Approved research can investigate markets, competitors, public complaints, and prospects with source-linked output.

X / Twitter

Live with OAuth

Approved X/Twitter work can publish and collect replies through a connected account.

Cold email

Beta · Gmail required

Email execution depends on Gmail and the approval mode shown on the task.

Reddit

Manual publication

Use research and reviewable drafts, then keep public posting in the founder's hands.

Ads

Plan-only

An ad hypothesis can be planned, but Soloop does not buy or manage the campaign today.

Coding

Live after approval

The Coding Agent can implement and test the approved product change in a sandbox.

Continue the loop

Test the page messageSeparate unclear copy from poor audience fit with a human study.Market research for startupsBuild context without confusing secondary research with demand.Get the first 10 SaaS customersTurn a supported hypothesis into a bounded customer cycle.SaaS competitor analysisCompare customer, job, trigger, proof, exchange, and friction.

FAQ

Questions before the next move.

Can I validate a SaaS idea before building?

You can test the problem, audience, language, and willingness to commit before building. This workflow focuses on founders with a real artifact because people can react to a concrete promise or workflow rather than an abstract description.

Is a waitlist proof that the idea is validated?

No. A waitlist can show attention and provide people to contact, but qualified use, return, and payment are stronger signals. Track each separately.

Does Soloop give a SaaS validation score?

No. Soloop is not positioned as a magic idea scorer. It helps structure approved research and execution so the founder can make a decision from inspectable evidence.

Bring the product you already have

Choose one move. Review it. Learn from the result.

Start with a URL, repo, landing page, demo, deck, file, or rough product.

Start with a project