Launching a New Product: The Pre-Launch Checklist to Run First
Launching a new product means release, readiness, announcement and distribution. Here is the timeline, the page checks to pass first, and how to get first users.
Launching a new product takes four jobs, in order: release the product so people can use it, make the page they land on ready for visitors and crawlers, announce it in the places your buyers already read, and keep distributing it after the first day. Most makers spend their effort on the announcement. The readiness work is what decides whether the day's attention sticks: a title and description that say what the product is, content in the HTML the server sends, a robots.txt that does not block crawlers, no stray noindex, working links, HTTPS, and a page that works on a phone. The product itself still matters most. In an analysis of the US car industry reported by All Things Innovation, the Brookings Institution found that lost market share "came down to the basic attributes of the cars", not "brand loyalty, distribution, styling, or other 'soft' factors". So build something people want, then make sure nothing on the page wastes the day they arrive.
This guide covers:
The difference between a release and a launch, and why it changes your plan
A launch timeline you can run, from research to the week after
Twelve page checks in the order you perform them, each with the usual failure and the fix
A copyable checklist template
What to do, and what to avoid, when you announce and promote
How to get the first users once the page works
What is the difference between a product release and a product launch?
Newsletter
What launched, every Monday
Every Monday: what launched on LaunchScaler that week, what is launching next, and the reviews we published. Confirm your email once and you're in.
A release is the technical event: the build becomes available to users. A launch is the market event: you announce the product, explain it and send people to it. They can happen on the same day or weeks apart, and separating them is usually the safer choice for a small team.
Release
Launch
What happens
Code ships to production
The product is announced and promoted
Who notices
Existing users, testers, crawlers
New visitors from posts, newsletters, communities
What can go wrong
Bugs, broken signup
A page that fails when attention peaks
Can it be repeated
Every deploy
Rarely; a second first impression is hard to get
Decides
Whether the product works
Whether people hear about it and stay
The rule that follows: release quietly, run the page checks below against the live product, fix what they find, and launch only once the page passes. A release can be patched within the hour. A launch post that sent people to a broken page cannot be recalled.
What does a product launch strategy include?
A launch strategy is the plan for getting a shipped product from unknown to used. For a solo maker or a small team it answers five questions:
Who is it for? One buyer, described by the job they are trying to finish, not a demographic.
Where do those people already gather? The communities, directories, newsletters and social accounts that cover your category.
What will you say? One sentence on what the product does and for whom, plus one concrete reason to try it today.
When? A launch day you choose, with time before it to fix what testing finds.
Where does everyone land? One canonical page that does its job for a person and a crawler.
The research behind question one does not need to be heavy. Exploding Topics describes market research for new product development as "the process of evaluating the demand, growth, and gaps in a market for a particular product". For software, that usually means reading the threads where your buyers complain, talking to five or ten of them, and checking which questions they type into search. Many researchers now lean on AI for this work: a survey Columbia Business School ran with GBK Collective found that "45% of them were already employing gen AI in their current data and insights activities", as Columbia Business School reports. The same survey found that "more than 70% of respondents reported concerns about the possible side effects and challenges of gen AI", which is a fair warning: use AI to sort what buyers say, not to invent what they want.
A launch timeline you can run
The exact length depends on how much is unfinished. Use this sequence as the order of work; stretch or compress the gaps to fit.
Several weeks before: confirm the problem. Talk to the buyers from question one. Write down the words they use for the problem; those words become your headline and your title tag.
Two to three weeks before: release to a few people. Ship to production and invite a handful of testers. Fix the signup and the first useful screen before anything else.
One to two weeks before: run the page checks below. Run them on the production domain, not on staging. This is where most avoidable launch failures are found.
One week before: prepare the announcement. Write the post, the short version for communities, the newsletter pitch and the screenshots. Book any directory listing or launch day slot you plan to use.
The day before: freeze and recheck. Make the last deploy, then run the full page check again. Check every preview card.
Launch day: post, then answer. Post in the places you chose, at times your audience is awake, and reply to every comment and question.
The week after: follow up. Email the people who signed up, fix what they report, and publish one page answering the question you heard most.
Where it fails. The usual failure is compressing steps 3 and 5 because the announcement feels urgent. If anything in step 3 fails and cannot be fixed in time, move the launch day. A launch can move a week. Shares cannot be recalled.
The pre-launch page checklist, step by step
These checks assume you own the site and can change its HTML and hosting settings, and that you have a terminal with curl (browser developer tools work too). On a hosted builder where you cannot set headers, run every step anyway and record what the platform sends.
The worked example is a fictional invoicing tool, Ledgerline. Its maker built the site in a JavaScript framework, deployed on a host with preview deployments, and moved from a staging subdomain to the real domain two days before launch. That history is common, and it produces most of the failures below.
1. Pick one host and redirect the others to it
Decide whether the product lives on the www host or the bare domain. Then run curl -sI against all four combinations: HTTP and HTTPS, with and without www. Exactly one should return 200. The other three should return 301 or 308 with a Location header pointing straight at it.
Where it fails. Both hosts return 200, so launch links split between two addresses. Or the redirect is a 302 (temporary), or it chains through two hops.
Recover. Set one permanent redirect at the host or DNS provider, straight to the final address. Ledgerline's www host returned 200; one redirect rule in the hosting dashboard fixed it.
2. Serve everything over HTTPS, with no mixed content
Click the padlock: the certificate should be valid for the exact hostname. Then open the developer tools Console and reload. A "Mixed Content" warning means an image, script or font loads over plain HTTP.
Where it fails. The certificate covers the bare domain but not www, so the redirect from step 1 shows a warning first. Or an image still points at the old staging host.
Recover. Issue the certificate for every hostname you redirect from. Replace hardcoded asset addresses with HTTPS or relative paths. Ledgerline had two hero images still pointing at staging, the first sign that staging values had leaked into the build.
3. Send the security headers, and test the strict one first
Run curl -sI on the production URL and look for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, and framing protection (frame-ancestors in the policy or an X-Frame-Options header).
Where it fails. The serious failure is not a missing header. It is a Content-Security-Policy written the night before, which blocks your own analytics, payment form or chat widget, so signups stop and nobody knows why.
Recover. Ship the policy as Content-Security-Policy-Report-Only, walk the full signup and checkout path with the console open, allow every legitimate source that shows a violation, then switch to enforcing. If you cannot test the payment flow before launch, keep Report-Only on launch day and enforce the following week. A working checkout matters more that day than a perfect policy. Start Strict-Transport-Security with a short max-age, because browsers remember it.
4. Read robots.txt as a crawler would
Open /robots.txt on the production domain and read every User-agent group and Disallow line. Confirm it returns 200.
Where it fails. The staging file, with User-agent: * and Disallow: /, was deployed to production. This is a frequent reason a launched product never appears in search. Other failures: the file returns a server error, or a copied template blocks AI crawlers you actually want.
Recover. Remove the site-wide Disallow. Block only private paths such as /app/ or /api/, and add a Sitemap: line with the absolute sitemap address. On AI crawlers, the deciding condition is simple: if you want answer engines to read and cite your pages, do not block the crawlers they use to fetch them. Each company publishes its crawler names; decide per crawler. Ledgerline replaced the staging Disallow: / with two private-path blocks and the sitemap line.
5. Remove every stray noindex and nosnippet
robots.txt controls crawling. noindex controls whether a crawled page may appear in results, and it arrives in two places.
View the page source (not the Elements panel) and search for robots. A meta tag containing noindex, none, nosnippet or max-snippet:0 needs a reason to be there.
Run curl -sI and look for an X-Robots-Tag header. It never appears in the page source, which is why it survives so many launches.
Repeat on pricing, docs and every page you will link on launch day.
Where it fails. A CMS "discourage search engines" setting travelled from staging with the database. A host adds X-Robots-Tag: noindex to preview deployments, and the domain is attached to a preview. A nosnippet added to hide one table now stops engines quoting any text from the page.
Recover. Remove the directive at its source, redeploy, recheck with curl. The longer list of causes, in order, is in why your new site isn't showing up on Google. Ledgerline had no meta tag, but curl showed the header, because the domain pointed at a preview environment.
6. Point the canonical tag at the live URL
Find <link rel="canonical" in the source. Its href should be the absolute production address of that same page, on the host from step 1.
Where it fails. It points at staging, at localhost, at the redirected host, or at the homepage from every page, quietly sending the page's signals elsewhere.
Recover. Generate canonicals from one configured site URL in production environment variables. Ledgerline's canonical pointed at staging; fixing the site URL variable also fixed the images from step 2.
7. Write a title and description that describe the product
Pull the <title> and the name="description" tag from the served page and read them as a stranger seeing a search result.
Where it fails. The title is a framework default ("Create Next App", "Home") or only the brand. The description is template text, repeated on every page, or missing.
Recover. Name what the product is and who it is for, brand last. Give every launch-day page its own pair, and put only claims in the description that the page supports.
Template: title and description
Title: [What it is] for [who], [key difference] | [Brand]
Description: [Brand] [does what] for [who]. [One concrete detail: how it works or what it replaces].
Ledgerline title: Invoicing for freelance designers, paid in any currency | Ledgerline
Ledgerline description: Ledgerline sends invoices, chases late payments and converts currencies for freelance designers. Connect your bank and send your first invoice.
8. Make sure the content is in the HTML the server sends
Many crawlers and AI fetchers read the HTML the server returns, and some do not run JavaScript. Pick your headline and one distinctive sentence, then run curl -s on the URL and pipe it to grep for that sentence. If the response holds little more than an empty root div and script tags, the content is not served.
Where it fails. A single-page app renders everything in the browser, or pricing and FAQ load from an API after the page mounts.
Recover. Use server rendering or static generation for public pages; the app behind login can stay client-side. If that is not realistic before launch, prerender the handful of public routes. Ledgerline moved its pricing table into the static build, and the grep found it.
9. Set the social preview tags
Launch day is mostly shares, and each platform builds its card from og:title, og:description, og:image, og:url and twitter:card. The image address must be absolute and on the production domain. Send the link to yourself on each platform you will post to.
Where it fails. A relative or staging image path gives an empty card, or the platform cached a placeholder during testing.
Recover. Use absolute HTTPS images and the platforms' own debugging tools to refresh the cache, the day before, not after posting.
10. Click every link a launch visitor will click
Walk the page as a newcomer: navigation, buttons, footer, signup through to the first app screen, pricing, docs, terms and privacy. Then crawl the public site with a link checker. Request a path that does not exist; it should return 404, not 200.
Where it fails. "Sign up" still points at the staging app, legal pages exist only on staging, or unknown routes return 200.
Recover. Fix links at the source and configure real 404 responses. Ledgerline's crawl found a broken "Docs" link and a privacy page that existed only on staging.
11. Load the page on a real phone
Many launch links are opened inside social and email apps, often on a phone. Confirm the viewport meta tag, test a narrow width in device mode, then open the production URL on an actual phone on mobile data.
Where it fails. A wide pricing table forces sideways scrolling, a sticky header and consent banner leave a sliver of screen, or form inputs zoom the page.
Recover. Let wide tables scroll inside their own container, trim fixed elements on small screens, and test the whole signup flow on the phone.
12. Submit a sitemap, then re-run everything after the last deploy
Open /sitemap.xml: it should list only canonical production pages you want indexed. Verify the production domain in Google Search Console, submit the sitemap, and use URL Inspection on the home page. Then, after the final deploy and again on launch morning, repeat steps 1 to 11.
Where it fails. Search Console was verified on staging, or the last deploy came from a branch with staging variables and steps 4 to 6 regress at once.
Recover. Generate the sitemap from the same site URL setting as step 6, and keep the checks as a saved list so a full pass takes minutes.
The checklist, as one copyable template
Pre-launch checklist
One host returns 200; the other three return a single 301 or 308 to it
Valid certificate for every hostname; no mixed content warnings
Security headers present; Content-Security-Policy tested in Report-Only first
/robots.txt returns 200, has no site-wide Disallow, lists the sitemap
AI crawlers allowed or blocked by decision, per crawler
No noindex or nosnippet in meta tags or X-Robots-Tag headers on public pages
Each canonical is the page's own absolute production address
Unique title and description on every launch-day page
Headline and key sentences found by curl in the served HTML
Preview tags with an absolute production image; cards checked
No broken links; unknown paths return 404
Page and signup flow tested on a real phone
Sitemap lists only canonical production pages; production domain verified
Full pass repeated after the last deploy and on launch morning
Ledgerline failed steps 2, 4, 5, 6 and 10 for one reason: staging values that travelled to production. When several checks fail together, look for the shared cause before fixing them one by one.
How do I announce a new product launch?
Write one short announcement that says what the product does, who it is for and where to try it, then adapt it to each place you post. Link every version to the same canonical production page.
Do
Avoid
Lead with the problem in your buyers' own words
Leading with the technology or a list of features
Post where your buyers already read, and follow each community's rules
Posting the same link in every forum on the same hour
Show the product: a screenshot, a short clip, a live demo
Mockups that do not match what people find after signing up
Say plainly what is free and what is paid
Hiding the price until after signup
Disclose your role when you post about your own product
Asking friends for upvotes or posting fake reviews
Stay online on the day to answer questions
Posting and disappearing until the next morning
Ask newsletters and curated lists in your category to consider it, with a short pitch
Mass-emailing editors a press release
The announcement's job is to send the right people to a page that works. Its wording matters less than whether the page holds up when they arrive.
How do you get your first users?
Launch-day visitors are not users yet. The first ten or twenty usually come from direct work, not from the post.
Contact the people you interviewed. They described the problem; tell them it is solved and ask them to try it.
Answer existing questions. Find recent threads where someone asks for exactly what you built and reply with a useful answer, mentioning the product only where it fits.
List on directories that are crawled and indexed. A listing page that stays up keeps sending visitors after launch day; the published guide on how to get backlinks for a SaaS product covers which ones are worth it.
Make onboarding personal. Email each new signup yourself, ask what they hoped to do, and watch where they stop.
Where it fails. Makers stop after launch day because the traffic drops. The traffic always drops. What lasts is the indexed pages and listings that keep being found, which is why the page checks come first.
What a clean pass does not do
Passing every check makes the page readable, indexable and safe to share. It does not create demand, and it does not guarantee that search engines or answer engines will rank or cite the page; it removes the reasons they would skip it. Indexing also takes time after launch day, so a page that passes may still be missing from results for a while. Checklists also fail in two quiet ways: they are run on staging instead of production, or they check the repository instead of the response. Your code may set the right tag while a host rule or CDN serves something else. What counts is what a crawler receives.
A tech launch, run through LaunchScaler
Here is how a maker launching on LaunchScaler works through the same sequence, using its real workflow. After the quiet release, they paste the production URL into the free readiness scan. With no account needed, it runs 156 checks across 6 of its 7 categories, each scored out of 100 with the evidence behind the verdict. It checks what a visitor or crawler receives from the live site, not what the repository says, and covers search and answer engines in one pass. The maker fixes what it flags and scans again after the last deploy, which turns step 12 into a few minutes rather than an evening.
Then comes distribution. A free listing on the LaunchScaler directory is permanent, and it carries a dofollow link only once the site passes the readiness bar; the tiers are on the pricing page. Paying for anything does not change the verdict: every site is measured against the same bar. For what an automated pass can and cannot tell you, see free SEO scanner: what it can tell you, and exactly where it stops.
Your next step
Today, run steps 4, 5 and 8 on your production URL: read /robots.txt, run curl -sI and look for X-Robots-Tag, and grep the served HTML for your headline. Those three catch the failures that make a launched product invisible. Then pick your launch day with at least a week of margin, work through the rest of the template before the last deploy, and draft your announcement against the do's and don'ts above.
If you would rather see every check against your live site in one pass, with the evidence for each: Run the free scan.
Questions people ask about launching a new product
What is an example of a new product?
For a solo maker, a new product is usually a web app, a browser extension, a developer tool or a template, released at its own URL. A new version of an existing product counts too when it is announced and positioned on its own, such as a mobile app for an existing web service or a new paid tier with its own page.
Should the release and the launch happen on the same day?
Only if the product has already been tested in production by real users. Otherwise release first, run the page checks, fix what they find, and launch once the page passes.
How long should a product launch take?
Long enough to confirm the problem, test in production, fix the page and prepare the announcement. The timeline above gives the order; the gaps depend on how much is unfinished, and moving the date is cheaper than launching a broken page.
Catch SEO regressions after a deploy: baseline production, then re-check robots.txt, noindex, canonicals, redirects, raw HTML and certificates on every release.
A full website audit checks seven areas, not just SEO: search, AI visibility, backlinks, security, compliance, speed and visual, and whether your site works.
The free SEO tools that read your live site: Search Console, Bing Webmaster Tools, PageSpeed Insights, Rich Results Test, a crawler and a readiness scan, in order.
