Validation Pages

What this is for

Give a product idea a small, honest surface area where the right people can understand it, respond to it, and help you decide whether it deserves more work.

When this helps

• A fake-door test is only a label in a tracker, with nowhere useful for a customer to respond.
• Landing-page copy overpromises before the team knows whether the problem is real.
• Interest, form submissions, and the original hypothesis live in separate tools.
• Teams measure clicks but lose the qualitative reason behind the click.

How it works

A validation page is attached to one Experiment Tracker record. Specky generates or accepts structured copy for the audience, problem, benefits, test steps, and call to action. When you publish it, the page gets a shareable /validate/<slug> URL. Page views, unique visitors, CTA clicks, form starts, and responses are recorded against the page; each response becomes an EXPERIMENT_RESPONSE node linked back to the experiment so the next decision has both numbers and language. For an experiment with multiple concepts, configure one control and up to five active variants. Visitors receive a consistent weighted assignment, and the analytics view compares conversion with Wilson 95% intervals, sample-size readiness, privacy-safe UTM segments, and an optional guardrail. The verdict stays cautious while the sample is small. When the hosted page is ready, you can also deliver it to the connected GitHub repository: the GitHub App (or explicit OAuth fallback) uses the workspace-selected repository and default branch, then creates or updates a specky/validation/<slug> branch with a complete static fake-door page, validation.json, and a README. The branch links back to the hosted response page instead of creating a disconnected copy.

Before you start

• An existing experiment with a hypothesis and method such as fake door, waitlist, prototype, concierge, or feature interest.
• The audience and problem you want to test.
• Optional success criteria, such as “10% of qualified visitors request access” or “five target users describe this as a weekly problem.”
• A decision you will make after the test: continue, change the concept, run a deeper interview, or stop.

What you should see

• A draft landing page with honest, editable copy and a previewable visual treatment.
• A public URL with a focused CTA and no account required for respondents.
• Metrics for views, unique visitors, CTA clicks, form starts, responses, and conversion.
• For configured variants: assignment counts, per-variant conversion, Wilson 95% intervals, sample-size readiness, UTM segments, guardrail status, and a cautious verdict.
• Graph evidence containing the response language and a link back to the experiment.
• An optional GitHub branch with a working framework-neutral fake-door page, manifest, and README for internal review.
• A clean hand-off to the experiment completion flow, where the result can update assumptions, opportunities, decisions, and notifications.

Try it now

1. Open Experiments and create or expand the experiment you want to test.
2. Choose Create validation page. Let Specky draft the page from the hypothesis, description, success criteria, and linked context, then edit the copy until it sounds like your product and your audience.
3. Keep the page in Draft while checking the audience, promise, CTA, and decision rule. Do not publish a claim you cannot support.
4. If you need to compare concepts, open Experiment analytics, define a control and variants, set traffic weights, and record the baseline, minimum detectable effect, expected direction, and any guardrail floor before publishing.
5. Publish the page and share the /validate/<slug> link with the audience you actually want to learn from. Assignment is sticky per visitor so a returning person does not silently switch versions.
6. If the idea needs to be felt in the product context, choose Create GitHub branch. With the GitHub App installed, Specky uses the selected repository and default branch; it writes the test to a new specky/validation/<slug> branch and can optionally open a draft PR for engineering review.
7. Review the page metrics and analytics. Look for qualified intent and repeated problem language, read the confidence interval and sample readiness, and treat small segment cuts as directional rather than conclusive.
8. Complete the experiment and record what the evidence means. Link the result to the next decision or follow-up test.

A real example

Hypothesis: “If small SaaS teams could see why signups dropped without stitching together PostHog, support, and Slack, they would request an evidence brief.” Create a fake-door page titled “A calm answer to why signups changed,” publish it to a handful of product leaders, and measure qualified requests plus the language in their responses. A high click-through with vague responses means the promise may be interesting but the job is unclear; a smaller number of detailed requests may be stronger evidence.

Your next move

Use Experiment Tracker to record the verdict, then connect the result to Outcome Intelligence or a Decision Log.