A launch page has one job that no other page has: it must sell something the visitor has never heard of, to people who arrived out of curiosity, in a window that closes in days. Most launch pages fail because they are written as if the product were already known. Here is how to write the launch-day page, what to put in its place when the noise fades, and how to run an offer that does not teach your market to wait for the next one.
On launch day the visitor arrives from a tweet, a newsletter, a community post, or a friend's message. They know roughly nothing about the product, they are mildly curious, and they are comparing you to the ten other things they opened in tabs that morning. Two weeks later a visitor arrives from a search query or an ad. They have a problem, they are looking for a solution, and they have never heard of your launch. Writing one page for both is how teams end up with a hero that says "We're live!" to someone who does not know what "we" is.
The launch-day page leans on the moment: who built it, why now, what early adopters get that later buyers will not. The evergreen page leans on the problem: what the visitor is trying to do, how the product does it, and why it beats the thing they are using today. The practical move is to write the evergreen page first, because it forces you to state the promise without the crutch of excitement, and then adapt it into the launch version rather than the other way round.
If you only have time for one, build the evergreen page and add a launch strip to the top of it. A page that can sell to a stranger with a problem will also sell to a curious early adopter; the reverse is not true.
Before you point launch traffic at the page, a landing page audit shows whether the promise, the proof and the next step survive a cold read.
Use this as a map. Each section exists on both pages, but what it has to do is different.
Launch day: the promise plus a reason the day matters, such as early access or a founding offer. Evergreen: the promise alone, written for someone mid-problem who will never know there was a launch. If your evergreen headline still contains the word "launch" a month in, it is talking to a crowd that already left.
Launch day: borrowed and early proof, such as beta users, waitlist size stated honestly, the founders' own track record, or the specific problem that made you build it. Evergreen: results from real customers, named and specific. The launch page proves the team is credible; the evergreen page proves the product works.
Launch day: something that is genuinely only available now, framed as access rather than a discount. Evergreen: the standard offer, with a clear reason to start today that does not depend on a date. A launch offer that quietly becomes permanent tells every later visitor the list price is fiction.
Launch day: often a lower-commitment ask, such as claim early access or start the trial, because trust is thin. Evergreen: the real conversion action, with the trial or demo as the secondary path.
Launch day: warm, curious, high-volume, low-intent. Evergreen: colder, lower-volume, higher-intent. A launch page converting poorly on day one may be fine; an evergreen page converting poorly on search traffic that typed your category is a page problem.
A known product can open with its name. An unknown one cannot, because the name carries no information. The launch headline has to do three jobs in one line: anchor the visitor to a category they already understand, name the specific change the product makes, and give a reason to believe it that does not depend on reputation you do not have yet.
Anchoring is the step most launch pages skip. "A new way to think about work" anchors to nothing, so the visitor has to read the whole page to find out whether this is software, a service, or a newsletter. "Invoicing for freelancers who hate chasing payments" anchors instantly: the visitor knows what shelf it sits on and whether they are the person it is for.
The change is the before-and-after in the visitor's own terms. Not the feature, the consequence: not "automated reminders" but "invoices that chase themselves so you stop writing awkward emails." Write the before as the thing they already complain about, and the after as the thing they would describe to a colleague.
The reason to believe, on launch day, is usually the origin: who built it and the specific problem that made them. "Built by two freelancers who spent a year chasing late invoices" is weaker than a customer result but far stronger than an adjective, and it tells the visitor the makers understand the problem from the inside.
You cannot show results you do not have. You can show that the product has been used by real people who chose to say something about it. Collect this before launch, not after.
Even a handful of people using the product for two weeks produces more usable proof than a thousand waitlist signups. Pick users who match the buyer you want, give them the real product, and ask them to use it for a specific task rather than to "take a look."
After the beta, ask each user one question: what did this change for you, in your own words? A reply like "I sent my first invoice reminder without rewriting it four times" is a testimonial. A five-star rating from the same person is decoration.
A quote with a first name, a role and a company type is believable; an anonymous quote reads as written by you. Ask for the minimum context that makes the quote checkable in principle, and never publish a name without an explicit yes.
If you have a waitlist, say the real number or say nothing. If early users shipped something with the product, show the thing they shipped, with their permission, rather than describing it. Screenshots of real use beat statements about real use.
For a product nobody knows, the team is part of the proof. A short note on why you built it, with real names and faces, does more for trust than a logo strip of tools you integrate with. It is a credential, not a biography.
A launch offer should reward being early, not establish that the price on the page is negotiable. The difference is what the visitor learns about you when the offer ends.
Early access to a feature, a longer trial, direct line to the team, or a founding-member badge that stays after the launch all reward earliness without teaching that waiting earns a cheaper deal. A plain percentage off does the opposite: it tells the next visitor to wait for the next sale.
A founding plan whose terms will not rise for those who join during launch is honest urgency: the benefit is real, the deadline is real, and later buyers see that early buyers were treated well. State the end date and keep it.
If the launch offer ends on a date, it ends on that date. Extending it "by popular demand" is the single fastest way to convert a launch audience into people who never buy at full terms.
Visitors who see a launch offer wonder what comes next. Tell them: the plan, the terms after launch, and when they change. Transparency here reads as confidence, and it stops the question from becoming an objection.
Two or three weeks after launch the traffic changes and the page must change with it. Schedule this rewrite on the day you launch, or it will not happen.
Every reference to launch week, to "now live," to the founding offer that has ended, comes out. A visitor arriving from search should not be able to tell the page was ever a launch page.
The founders' story moves lower; the first real customer results move up next to the headline and next to the button. If you collected specific sentences during the beta and the launch, this is where they go.
Read the launch headline cold and ask whether someone who typed your category into a search box would understand it. Usually the category anchor stays and the launch hook is replaced by the clearest version of the change.
Launch week produces support messages, replies and comments. The questions that repeat are the objections the page did not answer. Add a short section for each, phrased as the visitor phrased it, and place it before the final call to action.
The evergreen page needs its own reason to act today that does not depend on a calendar: the cost of the problem continuing, a cohort start, a real capacity limit. If there is none, say nothing; invented urgency on an evergreen page costs more trust than it earns.
Run this the day before you announce.
A product launch landing page should include a headline that anchors the product to a category the visitor already understands and states the specific change it makes, a short subhead with the reason to believe, early proof such as beta user quotes with names and context, a founder note explaining why the product exists, a launch offer that rewards earliness with access or locked terms rather than a bare discount, and one dominant call to action labelled with the outcome. It should also carry a stated end date for the launch offer and a plan for what the page becomes when launch week is over.
Usually not, or at least not the same copy. A launch page speaks to warm, curious visitors who arrived from an announcement and know nothing about the product, so it leans on the moment, the team and early access. An evergreen page speaks to colder visitors who arrived with a problem and never saw the launch, so it leans on the problem, the result and real customer proof. The practical compromise is one URL whose copy is rewritten a few weeks after launch: write the evergreen version first, add a launch layer on top, then strip the layer off.
Reward being early with something other than a lower price: early access to a feature, a longer trial, direct access to the team, a founding-member status that persists, or plan terms locked for anyone who joins during the launch window. State the end date, say what the standard offer will be afterwards, and let the deadline pass without extending it. A bare percentage off trains the market to wait for the next sale and tells later visitors the list price is negotiable; locked terms and access do neither, and they leave early buyers feeling well treated when later buyers see the standard offer.
Schedule the rewrite for two to three weeks after launch, on the day you launch, so it actually happens. By then the traffic has shifted from announcement visitors to search and ad visitors, the launch offer has ended, and you have a stack of support questions and comments showing which objections the page failed to answer. The rewrite removes every date reference, moves real customer results up next to the headline and the button, rewrites the headline for a stranger with a problem, adds a short section for each repeated question, and replaces calendar urgency with a reason to act that stays true.
Run your page through the same diagnostic. The free preview takes about a minute — no signup.
Audit my page