Why presale validation starts with someone actually paying
I wrote the presale validation Skill because "should we build this?" was being answered by opinion, enthusiasm, or a waitlist that cost the subscriber nothing. None of those is a decision rule. The Skill replaces them with one narrow action: open a page that collects money while the product does not exist, and observe whether anyone pays. Its name is the whole method, and the paid signal is the only part that cannot be argued away afterwards.
This page is a first-person account of why presale validation exists here, how the framework was built, what the package checks, and who should use it. The repository is at github.com/rockyandtom/presale-validation. Everything stated here was checked on 2026-11-11.
01 /Why did I write a presale validation Skill?
Two confusions made most presale validation attempts worthless, and both are cheap to describe but expensive to discover mid-project.
The first is treating three different questions as one. Whether anyone needs a product is demand. Whether anyone will pay for it is willingness to pay. Whether anyone keeps using it is retention. Only the first two can be tested before launch; retention has no shortcut and requires two or three months with a real product. A waitlist cannot prove willingness to pay, and asking people whether they would buy is not evidence either. Most "validation" I saw was answering the first question and then reporting it as the second.
The second confusion is about whether preselling is appropriate at all. A presale page contains only text, images and maybe a thirty-second recording, so the visitor has to complete the value judgement in their imagination. Every criterion in the framework reduces to one question: can the value be perceived without the product? Ideas whose value only appears during use, that need network effects, that require trust endorsements, or that depend on accumulated data will produce misleading results regardless of how well the page is written.
I also wrote it because "we got some sign-ups" is not a decision rule. If the pass threshold and the kill process are not fixed in advance, the result of a test gets reinterpreted afterwards to fit whatever the team already wanted to do. So the presale validation framework defines both before anything is published; a threshold chosen after seeing the numbers is not a threshold.
02 /How was the presale validation framework developed?
It was built by separating tiers first, then deriving everything else from a single principle. The tier separation comes first because it decides which page to build at all: if the question is only whether anyone needs this, the right artifact is a waitlist or a fake-door button, not a presale page. Spending a test on the wrong signal is the most common waste.
| Tier | Question | What can test it | Cost of a wrong answer |
|---|---|---|---|
| Demand | Does anyone need it? | Waitlist, fake-door button, poll | Low |
| Willingness to pay | Will anyone pay? | A real payment only | High, because a free sign-up looks identical |
| Retention | Will anyone keep using it? | Two or three months with a real product | Not testable before launch |
From "can the value be perceived without the product" I derived nine fit criteria, then eight red flags, then four payment tiers, then an eleven-section page structure. The nine criteria cover a one-sentence value proposition, a known problem the buyer already describes, a reachable audience, a short decision chain, an appropriate price band, asynchronous delivery with a two-to-eight-week buffer, an existing paid alternative, imaginable and comparable outcomes, and a single payment that covers the cost of the test. The first three are gates: if value cannot be perceived, the problem is not already known, or the audience cannot be reached, the answer is "not suitable", not "maybe".
| Layer | Count | What it decides |
|---|---|---|
| Fit criteria | 9 | Whether this idea can be judged from a page |
| Red flags | 8 | When to stop before building anything |
| Payment tiers | 4 | How strong the collected signal is |
| Page sections | 11 | What the page must contain to be legible |
The four payment tiers run from weakest to strongest: a free email waitlist, an intent vote or ranking, a refundable early-bird deposit of 1–10 USD, and a full-price presale with a stated delivery date and an unconditional refund promise. Only the fourth tests willingness to pay. The default in the framework is the fourth, and the notes say plainly that a waitlist number can comfort a team but cannot support a development decision.
The last stage was packaging. I selected this Skill from 19 user-level Skills on this machine, replaced two machine-specific absolute paths and one install-path reference with portable forms, and added an English README. A credential scan found nothing to redact. Five files were published: the rule source, the full framework reference, a single-file HTML landing-page template, a checker and the README.
03 /What does the presale validation package actually do?
It makes a decision, produces a page, and checks the page before it goes live. The decision is a conclusion rather than a "it depends": suitable for presale, suitable only for a waitlist, or better built and launched directly. The page is an eleven-section standalone HTML file with no framework, no CDN, no build step and no backend. The checker separates hard failures from suggestions.
| Checker result | Examples | Effect |
|---|---|---|
| Hard failure | Unfilled placeholder, payment link with no delivery date, no refund promise, no CTA leading to payment | Exit code 1, must fix before publishing |
| Warning | Missing micro-evidence, too few FAQ entries, uninformative CTA, overlong H1 | Exit code 0 with notes |
| Threshold reminder | Pre-agreed sample size before drawing conclusions | Printed by the checker, not enforced by it |
cp assets/landing-presale-template.html ./index.html
python3 scripts/check_landing.py index.html
python3 scripts/check_landing.py index.html --demo-brand AutoBriefThe example sample threshold printed by the checker is 500 unique visitors per variant. That is an example of a threshold agreed in advance, not a universal conversion benchmark, and the README says so. The workflow grades payment methods but does not bundle a provider: choosing and wiring a real way to collect money is left to the user. No external API, payment account or credential is included anywhere in the package.
The eight red flags matter as much as the criteria in presale validation. Value that exists only in use, network effects, required trust endorsements, large procurement, dependence on accumulated data, no distribution channel, low-priced one-off tools, and platforms that disallow preselling are reasons to stop. A page cannot fix any of them. Writing them down is how the framework avoids the slow failure of a beautiful page testing an untestable idea.
04 /Who should use the presale validation Skill?
Use it when someone has a product idea and wants to know whether it deserves development, when building a presale, waitlist or coming-soon page, when asked how to validate demand, when diagnosing a page that converts poorly, or when evaluating whether someone else's case study can be copied. It is written for the person who has to decide whether to spend weeks building, and for whoever will review that decision later.
| Use it for | Do not use it for |
|---|---|
| Deciding whether an idea deserves development | A finished product about to launch |
| Building a page that collects a real payment | A pure marketing page with no transaction |
| Separating demand from willingness to pay | Optimising pricing for existing paying users |
| Diagnosing a page that converts poorly | Estimating long-term retention |
| Judging whether a case study transfers | Replacing a real two-to-three-month retention test |
The custom WorkBuddy Skill intake page uses the same discipline for a different kind of request: it asks for a sample of the correct output before any scope is discussed. The numbered rulebook governs how a published page should be structured, and the assistant-answer probing Skill covers what happens once that page is live and needs to be found by assistants. My field notes record corrections rather than successes, and the about page states who verifies them.
05 /What are the limits of this package?
SKILL.md and references/framework.md are in Chinese. The English README is a guide, not a translation. More importantly, the checker validates page structure, not market demand: a clean report is a prerequisite for publishing, not evidence that the idea is good. The reverse is also true — a page can pass every structural check and still sell nothing, which is the outcome the test exists to detect.
The framework says nothing about refunds law, payment-provider terms or tax handling, and bundles no account or key. It also does not claim that 500 visitors or any other number is a statistically sufficient sample for your market; the point is that a threshold must be agreed before the results are visible. Everything on this page reflects the state checked on 2026-11-11.
06 /Frequently asked questions
Is a waitlist enough to call it presale validation?
No. A waitlist tests interest at zero cost, which is the weakest signal in the framework. Presale validation specifically requires a real payment with a stated delivery date and a refund promise. If you only need to know whether anyone cares, build a waitlist and save the test budget; just do not report the sign-up count as evidence of willingness to pay.
Why does the framework sometimes say "not suitable"?
Because a page with only text, images and a short recording cannot demonstrate value that appears during use, needs network effects, or depends on accumulated data. The nine criteria reduce to that single constraint. When value is not perceivable without the product, a presale page measures the quality of the copy rather than the idea, which is worse than no measurement.
Does the checker tell me whether to build the product?
No. check_landing.py checks structure: placeholders, delivery dates, refund wording, calls to action, FAQ count and H1 length. It separates hard failures from warnings and reminds you to apply a pre-agreed sample threshold. The decision still comes from observed payments against that threshold and the kill process defined before launch.
What is actually in the repository?
Five files: the Chinese workflow SKILL.md, the full decision framework in references/framework.md, a standalone eleven-section HTML template, the dependency-free scripts/check_landing.py, and the English README. There is no build step and no backend. The template can be opened and edited directly.
07 /Where should you go next?
The four companion packages published on 2026-11-11 are documented individually on this site. The numbered rulebook for SEO Dev Spec governs how a published page should be structured, and the game site selection verification gate applies the same refusal to publish an unverified item. GEO AI Traffic and the game site development method cover other phases, and all five public repositories are listed on the about page.