Design · Create · Ops & Automation
Cheap parallel channel-test plan with pass/fail thresholds
I get a parallel channel-test plan where every test names one of the 19 canonical traction channels and carries a metric, a small budget, a duration, and a numeric pass threshold, so I can run several cheap experiments at once and read every result the same way.
You receive: A JSON object { tests: [{ channel, metric, budget, durationDays, passThreshold }] } describing the parallel channel-test plan.
Part of Distribution
Example
A sample of what this play produces. Your result is generated for your inputs.
Plan Note
STUD.com is pre-seed and pre-revenue, so this plan spreads a small cap across five cheap, parallel tests of the channels most likely to reach solo founders and small product teams. Content-led acquisition (SEO, developer documentation, launch communities) is already the working hypothesis, so three tests probe that thesis from different angles and two probe adjacent channels it has not tried. Every test reads the same way: hit the pass threshold inside the window or the channel drops out of the next cycle. Budgets are illustrative launch-scenario figures, not committed spend.
Tests
| Channel | Metric | Budget | Duration Days | Pass Threshold | Rationale |
|---|---|---|---|---|---|
| content marketing | waitlist signups attributed to published articles | 400 | 30 | 40 | The core content-led thesis: four articles on running plays instead of prompting, each ending at the waitlist. 40 signups is a fifth of the 200-signup launch scenario, a fair bar for the lead channel. |
| search engine optimization | organic sessions per week to play detail pages by day 45 | 300 | 45 | 150 | The 265-play catalog is itself a long-tail SEO surface: each play page targets one task query. SEO compounds slowly, so this test gets the longest window and a traffic bar rather than a signup bar. |
| community building | launch-community members who visit the catalog within 7 days of joining | 250 | 30 | 30 | Founders already gather in launch and indie-hacker communities STUD names as an acquisition channel. Measuring catalog visits, not raw joins, filters vanity membership. |
| engineering as marketing | waitlist signups from a free single-play tool page | 450 | 40 | 25 | Ship one play as a free standalone tool: the tool demonstrates the deliverable-with-acceptance-check mechanic better than any copy. Largest budget because it carries build cost, and the bar is signups, not traffic. |
| targeting blogs | referral visits converting to waitlist signups from guest posts and mentions | 300 | 30 | 15 | A cheap probe of borrowed audiences: pitch guest posts to the small blogs solo founders read. Lower threshold because each placement reaches a narrow audience, but a pass proves the audiences overlap. |
Budget Note
Planned spend is 1700 against a 2000 cap, leaving 300 held back to extend whichever passing test reads strongest.
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the plan is a JSON document under 120,000 characters with a tests list, that the plan has at least your minimum number of tests (default 3), that every test names one of the 19 canonical traction channels with no channel repeated, that every test carries a non-empty metric name, a budget greater than zero, a duration in days greater than zero, and a numeric pass threshold, and, only when you set a total budget cap, that the planned budgets add up to no more than the cap. STUD also rejects the run if the minimum-tests setting is outside 1 to 19 or the budget cap is not a positive number. STUD does NOT verify that the chosen channels fit your product or audience, that the metrics are measurable or the right ones to learn from, that the budgets or durations are realistic, or that the pass thresholds are sensible. Your product, customer, current-channel, and learning-goal answers are context for the operator and are not checked by the validator.
Get early access to STUD the day it goes live.