Validate before you build

The most expensive way to learn that nobody wants your product is to build it first. Most failed SaaS projects do not die from bad code or slow servers — they die from months of engineering spent on a problem nobody was desperate to solve. The fix is boring and proven: sell it before you build it.

That is why SynapseKit ships with a launch stage, and why the default for a new product is not "live" — it is "waitlist."

Waitlist mode is a stage, not a hack

Flip one value in config.ts and the entire product reshapes itself:

• The marketing site stays live: hero, features, FAQ.
• The main call to action becomes an email capture instead of a sign-up button.
• Sign-in and the app itself are blocked at the proxy — there is nothing to log in to, and that is the point.

You get a real, deployed, fast landing page at a real domain, collecting real emails into your own Postgres. No feature code exists yet. Total build time: an afternoon of writing copy.

What a good test looks like

A waitlist test is only as honest as its setup. Three rules:

1. Pitch one specific problem, not a platform. "Invoice reminders for freelance designers" beats "the modern billing workspace." A vague pitch collects vague emails, and vague emails teach you nothing.
2. Promise something concrete for signing up. Early access, founding-user pricing, a lifetime discount — give a visitor a selfish reason to hand over their address today.
3. Drive a known amount of traffic. Post where your audience already talks: a subreddit, a niche newsletter, a community Slack, or a small paid campaign. You need a denominator; 40 signups means nothing until you know whether 200 or 20,000 people saw the page.

Then watch one number: visitor-to-signup conversion. Rough benchmarks — warm traffic from a community that trusts you can convert at 10% or better; cold traffic converting around 2% to 5% is a real signal; cold traffic under 1% means the pitch, the audience, or the idea needs work. The built-in analytics give you visitors; the waitlist table gives you signups.

Emails are the start, not the result

The list is not the validation — the conversations are. Email your first twenty signups personally and ask about the problem, not the product:

• How do you handle this today?
• What have you already tried?
• What did those attempts cost you, in money or hours?

People joining a waitlist costs them nothing. People describing, in detail, a problem they have already spent money failing to solve — that is validation.

If replies are enthusiastic but abstract, be careful. If replies contain war stories and spreadsheets, build.

When to flip to live

There is no magic threshold, but the pattern is consistent: a conversion rate that holds up on cold traffic, plus a handful of interviews where people describe the same painful workflow in the same words, plus at least a few "can I pay you to get in early" messages. That combination almost never lies.

When you get there, flip the launch stage to live, and the machinery you skipped building during validation is already waiting: auth, organizations, Stripe billing, emails. Build the smallest version of the thing your interviews described — not your full vision — and charge for it from day one. Your waitlist is now a launch audience with intent, and the discount you promised is your first revenue.

The cheap answer to the expensive question

A waitlist that grows slowly is not a failure. It is a cheap answer to an expensive question — and getting that answer for the cost of a landing page, before you spend three months of nights and weekends, is the best trade in software. Some ideas will die at this stage. That is the feature working: every idea that dies as a landing page funds, in saved time, the one that deserves to be built.

Validate first. The code can wait; it is not going anywhere — and with a boilerplate underneath you, it was never the bottleneck anyway.