Every new RAXXO tool gets a waitlist page before it gets a product page
The list stays open for a fixed window, usually two to three weeks, never indefinitely
I email the list once, on launch day, and never before
The waitlist tells me what to build next more reliably than any survey
Why the Waitlist Comes Before the Product
Before a single line of marketing copy exists for a new RAXXO tool, a waitlist page exists. Not a landing page with a feature list, not a demo video, just a name, one sentence about the problem it solves, and an email field. That order matters more than it sounds like it should.
A product page written before the tool ships is a page written to convince myself the idea is good. It has bullet points that sound impressive and a mockup that flatters the concept. A waitlist page has none of that room to hide. One sentence has to do the whole job, and if I cannot write that sentence without reaching for jargon, the idea usually is not ready yet.
I learned this the hard way with Git Dojo. The first pitch I wrote was three paragraphs about "interactive terminal-first pedagogy." Nobody signs up for that. I cut it down to one line: "learn git by typing real commands, not by reading about them." That line became the waitlist headline, and it is still close to the actual homepage copy today. The constraint of the waitlist page forced the clarity that the eventual product page just inherited.
The other reason the waitlist comes first is sequencing. I ship in dark mode first and I test on my phone before my desktop, and a waitlist page is the smallest possible version of both tests. If a one-field form does not feel right on a phone screen, the full product will not either. Building the smallest page first surfaces those problems while they cost minutes to fix instead of days.
There is a quieter benefit too. A waitlist page is a commitment device. Once the page is live and even a handful of people have signed up, the tool has to ship. I have killed ideas at the note-taking stage plenty of times, the way I described in the RAXXO tool I killed before it ever shipped, but once a waitlist page is public, backing out means telling real people I changed my mind. That accountability is worth more than any project management trick I have tried.
What Actually Goes on the Page
The page itself is deliberately boring. A headline, one sentence under it, an email field, and a single button. No pricing, because pricing is not decided yet at this stage. No screenshots, because there is often nothing to screenshot. No countdown timer, because artificial urgency on a page nobody has heard of yet is just noise.
What the page does carry is a short line about who the tool is for, phrased as a filter rather than a pitch. For a developer tool, that might be "for people who ship solo and do not want a team-sized process." For something aimed at content creators, it might be "for people who post daily and are tired of re-editing the same clip five ways by hand." The filter line does more work than any feature description, because it tells the wrong visitor to leave quickly and the right one that the page was written for them specifically.
Below the email field, I add one honest sentence about timing: "launching in the next few weeks, one email when it is live." That sentence sets the expectation correctly. Nobody who signs up thinks they are getting early access to a beta or a stream of update emails. They are getting exactly one email, later, when there is something to use. I would rather under-promise on communication and over-deliver by staying quiet than build a list of people annoyed by a drip campaign they never asked for.
The page also always works without an account, the same rule every finished RAXXO tool follows. An email field is the only thing being asked for, no password, no account creation, no social login. If the point of a waitlist is to lower the barrier to expressing interest, adding friction at the exact moment someone is curious defeats the purpose.
I keep the design system consistent with the rest of the studio even at this early stage, reusing the same type scale and dark-first palette rather than a throwaway template. A waitlist page that looks like a hastily assembled form reads as a hastily assembled idea, and that impression is hard to undo later even after the real product looks polished.
How Long the List Stays Open, and Why I Close It
The waitlist window is never indefinite. I give it a fixed span, usually two to three weeks, and then either the tool launches into that list or the page comes down. An open-ended waitlist that sits live for months sends a signal I do not want to send, that the idea is stalled or that I am testing interest rather than committing to build.
The fixed window also protects the list itself. Email addresses collected today and emailed eight months from now feel like spam even when the sender remembers exactly why they signed up. People forget a one-line form they filled out on a page they do not remember visiting. A short window keeps the gap between interest and delivery small enough that the eventual launch email still makes sense to the person receiving it.
Closing the page does not mean deleting the interest. If a tool needs more build time than the window allowed, I take the page down, keep building, and put a fresh page up closer to the real launch date rather than leaving a stale form live with no update. A visitor landing on a waitlist page that has clearly not moved in months trusts the next one less.
I only ever send one email off this list, and it goes out on launch day, not before. No "just two more weeks" update, no "here's a sneak peek" teaser, no re-engagement email trying to win back people who never opened the first one. The list exists for exactly one message, and I protect that scarcity on purpose. A short list of people who open the launch email is worth more than a long list of people who have learned to ignore me.
That same discipline shows up in the beta group I text before every RAXXO tool ships. The waitlist and the beta group are different audiences with different jobs: the waitlist is broad and gets one email, the beta group is small and gets direct back-and-forth. Mixing the two, treating the waitlist like a beta channel, has always backfired when I have tried shortcuts there.
What the Waitlist Actually Tells Me
The number of signups matters less than people assume. A waitlist with forty names is not obviously more validated than one with twelve, because the population who happens to see a given page at a given moment is a small and biased sample of anyone who might eventually want the tool. Treating the raw count as a green light or a red light is a mistake I made early on and have since dropped entirely.
What the waitlist tells me reliably is which sentence on the page people actually respond to. I run two or three headline variants over the life of the window, not as a formal A/B test with statistical significance, just as a way to see which framing gets a form filled out versus which one gets a bounce. The sentence that performs best on the waitlist page is almost always the sentence that ends up on the real product page, because it already proved it can explain the tool to a stranger in one line.
The waitlist also tells me who is asking, when people reply to the confirmation email with a question, which happens more often than I expected. Those questions are unfiltered product feedback from someone who has not used the tool yet and has no stake in being polite about it. A question like "does this work with X" or "is this a one-time purchase or a subscription" tells me exactly what is unclear on the page, and I fix that clarity gap before launch rather than discovering it in reviews afterward.
None of this replaces the actual decision of what to build next. The waitlist is not a substitute for judgment about which problems are worth solving. It is a cheap, honest check on whether the one sentence I can currently write about an idea lands with anyone outside my own head, run before the far more expensive work of actually building the thing begins.
Bottom Line
A waitlist page is the smallest, cheapest test a solo studio has for whether an idea is ready to become a product. It forces a one-sentence pitch before any feature list exists, it tests the exact same design and mobile-first habits the finished tool will need, and it turns a private idea into a small public commitment that is harder to quietly abandon.
The discipline is in what the page does not do: no pricing before pricing is decided, no countdown urgency, no drip campaign, no indefinite open window. One sentence, one email field, one launch-day message, and a fixed span before the page comes down or the tool ships. That restraint is what keeps a short list valuable instead of turning it into another audience trained to ignore me.
The waitlist rarely tells me whether an idea is good. It tells me whether I can explain it, and whether the explanation survives contact with a stranger who owes me nothing. That is a smaller promise than validation, but it is one the page actually keeps, every time, before a single line of product code gets written.
Top comments (0)