You do not need a finished product to learn whether people want it. You need a specific promise, a credible page, and a way for interested people to identify themselves without creating a fake user database or turning your form into an email-spam endpoint.

This guide takes you from an idea to a verified startup waitlist in one day. The result is intentionally small: one landing page, one NamoID Test project, one branded waitlist, and one review process. That is enough to recruit design partners and decide what to build next.

What you are validating

A waitlist does not prove product-market fit. It can answer narrower, useful questions:

Does a clearly defined audience recognize the problem?
Will they give you a verified contact address to hear more?
Which acquisition message produces qualified interest?
Will applicants answer follow-up questions or accept an interview?
How many approved applicants return when early access opens?

Write the experiment before building the page:

Audience: Independent accountants serving Indian small businesses
Problem: Client identity documents arrive through insecure chat threads
Offer: A secure client-onboarding workspace built for Indian firms
Traffic source: 50 direct founder conversations + one LinkedIn post
Signal: 10 verified requests, 5 interview replies, 3 design partners
Decision date: 14 days after launch

Those numbers are an example, not a universal benchmark. Choose thresholds that would change your decision. “Get as many signups as possible” is not an experiment.

Morning: define the offer

Your first screen needs four things:

Audience: name who the product is for.
Problem: describe the painful situation in their language.
Outcome: state what becomes easier or safer.
Action: ask for early access with an honest expectation.

Weak copy:

The future of AI-powered business operations.
Join our waitlist.

Testable copy:

Collect client identity documents without email attachments.
 
We are building a secure onboarding workspace for independent accounting
firms in India. Request early access to join the first product interviews.

Do not invent customer logos, countdowns, capacity limits, or launch dates. Early users are evaluating the founder as much as the product.

Late morning: create the NamoID project

Sign in to the NamoID Console, create your tenant if this is your first visit, then create a project for the startup. A project represents the application you are validating.

Start in the automatically created Test environment. Test and Live have separate users, settings, keys, and hosted pages, so experimentation does not pollute the eventual production environment.

Use a recognizable project name and stable slug:

Project name: Ledgerly
Project slug: ledgerly
Environment: Test

You do not need an OAuth client or a custom authentication UI to launch the waitlist. NamoID Auth provides the hosted page for the environment.

Enable the verified waitlist

Open NamoID Auth inside the Test environment and set access to Waitlist. When waitlist mode is enabled, new visitors see the waitlist flow rather than ordinary signup.

Keep the first version simple:

Enable email as the identifier.
Require email ownership verification.
Add the product name and logo.
Set support, privacy, and terms links.
Use a reply-capable support address even when transactional mail is sent from no-reply.
Leave unrelated sign-in methods out of the new-applicant flow.

The ownership check is essential. Without it, anyone can submit another person's address and make your company send unsolicited messages. NamoID sends a short-lived code first and creates the pending waitlist entry only after the recipient verifies it.

That verification does not create an application user. Pending applicants stay in the Waitlist view until approved and later authenticated. Public forms also need layered rate limits on authentication endpoints, not one global traffic limit.

Brand the hosted page

Use the project's identity, not a generic “Coming soon” page. At minimum, configure:

Product name
Square logo that remains readable at small sizes
One primary brand colour with accessible contrast
Plain request and confirmation copy
Working privacy, terms, and support destinations

The page should explain what happens after submission:

Request early access
 
Verify your email to send your request. We review applications manually and
will email you if early access opens for your use case.

Do not say “Create account” if approval is not immediate. Do not call the verification code a login code when it only confirms a waitlist request.

Put the waitlist on your landing page

The fastest integration is a normal link to the environment's hosted waitlist page:

<a href="https://your-project-test.id.namoid.in/waitlist">
  Request early access
</a>

Use the exact hosted URL shown in the environment. Later, you can add a custom auth domain such as accounts.yourstartup.in, but a custom domain is not required to validate the idea.

Keep the landing page's primary action consistent. If the navigation says “Get started,” the hero says “Join waitlist,” and the footer says “Book demo,” visitors cannot tell what stage the product is in. Pick one action and repeat it.

Test the entire journey

Open the page in a private browser window and use an address you control. Verify all of these states:

The landing-page button opens the correct Test waitlist.
Submitting an email sends one verification message.
Resending creates a replacement code; the old code no longer works.
A wrong or expired code returns a recoverable page, not raw API JSON.
Successful verification creates one pending waitlist entry.
The applicant does not appear in the environment's Users list.
The confirmation page explains that review is pending and offers a sensible next action.
Approving the applicant sends the configured access-granted message.
Rejecting the applicant does not disclose internal review details.

Also submit from a phone. Authentication layouts that look correct on a desktop often fail when the mobile keyboard opens.

Afternoon: recruit the first applicants

Do not begin with broad paid traffic. Start with people you can speak to:

Ten people who experience the problem directly
Former colleagues or customers in the target role
A focused founder or professional community
One useful LinkedIn post explaining the problem and your proposed approach
Direct outreach that asks for feedback, not a favour to “boost” signup numbers

Send the landing page only after a short conversation whenever possible. The conversation tells you why the person joined; the signup alone does not.

Use source links rather than a complicated analytics stack:

/?utm_source=founder_outreach
/?utm_source=linkedin_problem_post
/?utm_source=accountant_community

Record the source with the experiment, but do not collect unrelated profile data “in case it becomes useful.”

Review applicants manually

For an early validation cohort, manual review is a feature. Look for evidence that the person matches the audience and has the problem you described.

Use three outcomes:

Approve: invite them to the next step.
Reject: they are clearly outside the current experiment.
Leave pending: you need a conversation or more context.

Give approved applicants one specific next action: schedule a 20-minute interview, complete a short onboarding questionnaire, or enter a private prototype. “You are approved” without a path forward wastes the moment of highest intent.

Measure behavior, not vanity

Track a small funnel:

qualified landing-page visits
  -> email challenges started
  -> verified waitlist requests
  -> interview replies
  -> approved design partners
  -> early-access activations

Raw signup count can be misleading. Twenty verified people from the exact audience who explain their workflow are often more useful than 2,000 unqualified addresses collected through a giveaway.

Review the words applicants use. Repeated language belongs in the next landing-page revision, product requirements, and sales conversations.

What not to build yet

Do not spend validation week building:

A referral leaderboard
Invitation tiers or artificial scarcity
A complex admin dashboard
Multiple user roles
A full billing system
Five authentication methods
Automated approval scoring
A newsletter campaign that applicants never consented to receive

Build those only when observed behavior creates the requirement. The purpose of the waitlist is to reduce uncertainty before code, not become another product to perfect.

Your one-day launch checklist

By the end of the day, you should have:

A written audience, problem, offer, and decision threshold
One focused landing page
A NamoID project with a Test environment
Waitlist access enabled in NamoID Auth
Email ownership verification
Product branding and legal/support links
A tested hosted waitlist URL
A manual applicant-review process
A list of the first ten people to contact
A date for evaluating the experiment

That is enough to begin learning. Create a Test project in the NamoID Console, launch the verified waitlist, and spend the rest of the day talking to the people who join it.

How to Launch a Startup Waitlist in One Day