75 shadcn Coming Soon Blocks: Waitlists, Countdowns, and Launch Pages for Next.js

The coming-soon page is often the first thing a product ships and the last thing anyone budgets time for. It looks like a hero with an email field, so it gets treated like one: paste a static section, wire an input, ship. Then the requests arrive. Add a countdown. Show how many people are waiting. Let the form say thanks instead of reloading. Move people up the queue when they refer a friend. None of that is static, and the moment it stops being static, a pasted hero stops being enough. So teams reach for a hosted "coming soon page" builder, inherit its branding and its rigidity, and rebuild it anyway the week the real site lands.

We think a launch page deserves the same treatment we gave landing pages, dashboards, and onboarding: real components you own, not a page you rent. With this drop the coming-soon category reaches seventy-five blocks. Rather than march through all of them, this post highlights sixteen of the best of the newest, the ones worth reaching for first. You can browse the whole category when you want the rest.

Two visual languages, one category

The sixty newest blocks come in two studio flavors, so a launch page fits the brand around it instead of fighting it.

Auralis is monochrome and editorial: oversized type, generous space, and a parenthetical eyebrow that reads like a caption. It suits studios, products, and portfolios that want to feel quiet and considered.

Polaris carries a single accent color, a square eyebrow, and seal-style buttons. It reads warmer and more product-like, and it is the natural fit when your launch wants a splash of brand color.

Both sets follow the same rules, expose the same kind of props, and mix freely with the earlier utility blocks (countdown timers, roadmaps, FAQ, and status boards) that opened the category.

What actually installs

Every block is a single React component, and the shadcn CLI resolves its whole dependency tree in one shot:

npx shadcn add "https://ui.beste.co/r/comingsoon36?email=YOUR_EMAIL&license_key=YOUR_KEY"

That command lands three things in your codebase:

1. The block at components/beste/block/comingsoon36.tsx. Plain TSX you own and edit.
2. The set primitive it uses (the Auralis or Polaris eyebrow and button), installed once and shared across every block from that set.
3. Nothing else. There is no runtime dependency on us, no waitlist provider, no license check in your bundle, and no email service you are locked into. The form is a real <form> with a submit handler you point wherever you want.

If you are on Base UI instead of Radix, swap /r/ for /r-base/ in the URL and you get the Base UI build of the same component. For the full command and license setup, see the installation docs.

Start with the capture

Most coming-soon pages exist to capture one thing: intent. So the core of the set is the notify form, and every one of them is a working form with a success state, not a decorative input.

comingsoon16 is the split waitlist: copy and capture on one side, a full-bleed image on the other. When the promise has a date attached, a ticking clock makes it real, and the countdowns run on a target date you pass in.

Launch pages that stand alone

Some of these are not a strip you drop between a hero and a footer. They are the whole page, built to stand on their own at the root of a temporary domain.

For launches where the layout is part of the pitch, comingsoon48 composes a headline, a notify form, an image, and social proof into a single bento grid.

Not every coming-soon lives behind a brand. comingsoon60 is the personal portfolio under construction, with a name, a role, contact links, and an availability status, ready for the root of your own domain.

The ones people remember

A few blocks lean on a strong idea rather than a single call to action, for launches where the design does the selling.

comingsoon51 renders early access as a physical ticket. For a page that fills up as people arrive, comingsoon73 turns each signup into a chip on a growing wall.

And when a teaser video says more than a paragraph, comingsoon33 sits it behind a play button that opens the clip in a modal.

A block for what you are actually launching

A restaurant, a conference, and a product drop all say "coming soon" in completely different shapes. Rather than bend one waitlist to fit them, the set covers the shapes.

comingsoon58 is the retail drop, prices blurred until launch. comingsoon56 opens a restaurant with hours and an address, comingsoon57 sells an event with a date, a venue, and a speaker row, and comingsoon68 teases an album for pre-order with a tracklist. comingsoon72 collects RSVPs for a gallery opening, and comingsoon74 announces a major version-two relaunch with a what-is-new grid.

Every value on the screen is a prop

The rule we held the whole category to is the same one behind the dashboard set: if you can read it, you can pass it.

Each block renders its full demo with zero props, so <ComingSoon36 /> looks exactly like the preview above. Every prop is optional and falls back to the demo value, so you replace demo copy with real content one field at a time instead of filling a config object before anything appears:

import { ComingSoon36, comingsoon36Demo } from "@/components/beste/block/comingsoon36";

export default function LaunchPage() {
  return (
    <ComingSoon36
      label="Launching Soon"
      heading="The doors to <strong>Halo</strong> open when the clock hits zero."
      targetDate="2026-10-24T09:00:00Z"
      labels={{
        placeholder: "Enter your work email",
        success: "You're on the list. We'll open the doors to you first.",
        proof: "3,400+ teams already counting down",
      }}
    />
  );
}

Every block exports its demo object too (comingsoon36Demo here), which doubles as documentation: the exact shape your data needs, in a file you can open. The interactivity stays yours and stays simple. The countdown takes a target date. The form holds its own email state and flips to a success message on submit, and the submit handler is a plain function you point at your own endpoint, whether that is a route handler, a form service, or your email platform. Nothing about the data leaves through us.

The details you would have had to get right yourself

• Server rendering is safe. Countdowns start at zero and only tick on the client, and there is no Math.random() in a render path, so the pages hydrate without mismatch warnings.
• The forms actually work. Real <form> elements, real submit handlers, a success state per block, and inputs that carry aria-labels. Wiring your backend is one function body.
• Mobile holds up. Split panels stack, countdowns reflow, and full-bleed heroes keep their text readable, because a launch page gets more phone traffic than desktop, not less.
• Theming is token-based. Everything reads from your CSS variables, so the blocks adopt your brand and your dark mode the moment they land. If you are still shaping those tokens, the anatomy of a shadcn theme walks through the variables these depend on.
• The code is yours. It is TSX in your repo, structured the way you would have written it, with no wrapper package to fork when a real requirement arrives. If your capture form needs validation, our forms deep dive covers the layer these pair with.

The sixteen at a glance

Every block links to a live, full-screen preview on its page. These are the highlights of the newest drop; the coming-soon category holds all seventy-five.

Some of the earlier blocks in the category, including the classic countdown timer and the simple waitlist, are free to install and try before you commit. The rest are part of Beste UI Pro.

Where these get discovered

We publish the whole catalog as a structured, machine-readable feed so search engines and AI assistants can index it directly, which is how a query like "shadcn coming soon blocks" can surface the right category instead of a wall of screenshots. That is the idea behind engines like shoogle.dev, which discover and rank sites through structured signals rather than crawling rendered pages. If you want your own component library to be found the same way, our MCP server exposes the catalog to assistants over the same kind of structured data.

Ship the page before the product

A launch page is the one thing you can put live before anything else is finished, and it is how you arrive at launch day with an audience instead of a countdown to silence. Pick a block that matches what you are building, install it, point the form at your list, and set a target date. Because every block ships complete, your page looks finished from the first commit, and you spend your time on the product it is promising rather than the page that promises it.