When apps ship faster, making customers wait needs a better reason.
You announce an app. Put up a landing page. Collect emails. Tell people something exciting is coming.
Meanwhile, someone else sees the same opportunity, opens a coding agent, and starts building.
By the time you send your “We’re almost ready” email, your prospective customers might already be using something else.
That’s the problem I have with the startup waitlist in the agentic building era. The time between having an idea and shipping a useful version has changed. I’m less convinced the launch advice has caught up.
If you can give someone something useful today, why ask them to come back later?
The old playbook had a reason
When building a product required months of engineering, a waitlist gave founders something to do with early interest. It could help test messaging, recruit beta users, and assemble an audience while the software took shape.
Linear and Superhuman are familiar examples. Linear selected early users from a waitlist and improved its product through small cohorts. Superhuman invested heavily in personal onboarding. Both approaches supported deliberate learning about customers.
But those strategies originated before today’s coding agents. They explain how the playbook developed. They don’t establish that its tradeoffs still make sense.
When the cost of delivering a working experiment falls, the case for collecting expressions of interest instead gets weaker.
An email address tells you someone liked your promise enough to submit a form. A person using your app can tell you where that promise breaks.
You’re giving competitors time, too
A public waitlist announces an opportunity before you’ve necessarily earned a customer.
That matters most for products whose core functionality is relatively easy to reproduce. Your announcement describes the problem. Your demo outlines the solution. Your signup count advertises interest.
A competitor doesn’t have to reproduce your whole roadmap. They only need to solve enough of the customer’s problem to become useful first.
This is a competitive risk, not an established law. I haven’t found research showing that waitlists routinely cause startups to lose their markets. Shipping first doesn’t guarantee winning, either.
Still, deliberately extending the interval between “I want this” and “I can use this” deserves scrutiny.
Your customer’s problem is happening now. Your launch schedule is yours.
What do the newer examples tell us?
Lovable’s own retrospective describes two unsuccessful launches in 2024, gradual onboarding from a waitlist, and an AI that still got stuck too often. The company attributes its eventual breakthrough to product improvements, a rebrand, and better communication. The list existed before the breakthrough; it wasn’t sufficient to produce one.
Manus complicates any declaration that restricted launches are dead. It entered invitation-only testing in March 2025 and subsequently reported $100 million in annual recurring revenue. That demonstrates commercial success following a restricted launch. It doesn’t tell us whether restricting access caused that success, or whether opening sooner would have worked better.
We should apply the same standard in both directions. A successful company that used a waitlist doesn’t prove the waitlist worked. A failed company that used one doesn’t prove it was the problem.
Inviting someone into a product is different
There’s an important distinction between collecting interest in an idea and controlling access to something people already use.
Instinct illustrates the invitation model: its public homepage includes an “Invite a friend” link. That alone doesn’t establish the company’s reasons for limiting access, but it points toward a different interaction. An existing user can bring someone else into the experience.
That feels more credible to me when the invitation leads to a working product.
There are reasonable constraints. You might only be able to support a few new customers each week. Agent usage might be expensive. You might need to observe failures before admitting more people.
Invitations can manufacture scarcity, too. The mechanism doesn’t settle the question. The reason for the restriction does.
The strongest defense: finding customers still takes work
Faster development doesn’t automatically create distribution.
One contemporary founder account makes this point well. Hado SEO’s founder reported collecting 80 waitlist emails and converting five into paying customers during launch week. Before launch, the founder spent time helping prospective customers in communities and refining the offer. These are self-reported results, but they describe customer conversion rather than a large signup number.
That’s a legitimate argument for a short prelaunch period. You can learn where customers gather, how they describe their problem, and whether you can reach them.
But it leaves a question: could you learn more by giving those same people a small, working product?
As building gets faster, that becomes a more practical alternative.
Make the wait justify itself
I’m skeptical of waitlists whose primary purpose is to make an unreleased app seem desirable.
A useful waitlist should correspond to something concrete: a capacity limit, a customer experiment, a dependency, or a product limitation you’re actively resolving. There should be a reason people are waiting and a condition under which they get in.
“Building hype” is a much weaker answer.
Before adding that email form, ask what you could ship to those people instead. One workflow. One useful capability. A limited version that does something well.
Then you can measure whether they use it, whether they return, and whether they care when it improves.
If someone else can ship a useful version of your idea before you finish building anticipation, what exactly are you waiting for?
