Pre-Launch Marketing Strategy for Developer Tools and SaaS

A pre-launch marketing strategy has one job: make sure that on launch day, a specific group of people is already waiting to try your product. Everything you do before launch (the pre-launch website, the waitlist, the content, the beta) should be judged by whether it grows or warms that group.

For developer tools, that group is small and sceptical. A few hundred engineers who understand the problem will do more for a launch than thousands of passive followers. This guide covers what to build, what to publish and what to measure in the weeks before you ship, and the mistakes that waste that time.

What pre-launch marketing is for

Pre-launch work does three things that are hard to do after launch:

• Validates the message. You find out which description of the product makes people sign up, while changing it is still cheap.
• Builds a warm list. People who opted in weeks ago open the launch email, try the product and leave the first comments.
• Starts search and reputation early. A domain and a few useful pages that exist before launch day have time to be crawled and linked.

It doesn't replace a product people can use. Several launch channels judge you on the product itself, so the pre-launch strategy has to work around their rules, not against them. Our product launch strategy guide covers the full timeline; this article zooms in on the weeks before day zero.

Build a pre-launch website that earns its traffic

A pre-launch website is usually one page. It still needs to do real work, and most "coming soon" pages don't.

Decide early whether the page should appear in search. For most products the answer is yes: let the real domain be crawled from the start, and keep only staging environments hidden. Don't rely on robots.txt for that. Google's robots.txt guide says it "is not a mechanism for keeping a web page out of Google" and points to noindex or password protection instead. Use a robots.txt generator for crawl rules and a meta tag generator for the title, description and robots meta tag.

Give the page a proper social preview too. Founders share pre-launch links in DMs, Slack and forums, and a blank preview card looks abandoned. The OG image generator makes one in a few minutes.

Help search engines find a one-page site

A single page on a new domain has a discovery problem, not a size problem. Google's sitemap overview says a site of "about 500 pages or fewer" might not need a sitemap, but also that a site that "is new and has few external links to it" might, because Googlebot may not find pages nobody links to. A pre-launch site is usually both small and unlinked, so the practical advice is cheap: add a sitemap anyway (a sitemap XML generator does it in a minute), verify the domain in Search Console, and get a handful of honest links pointing at it.

The easiest honest links are ones you control: your GitHub organisation profile, the repo README, your personal site and the bios of the founders' social accounts. If the product is open source, set the repo's social preview image as well. GitHub's social preview docs recommend 1280 by 640 pixels and a PNG, JPG or GIF under 1 MB, so a repo link pasted into chat looks as deliberate as your website link.

Before you share the page anywhere, run it through a heading structure analyzer so it has one clear H1 that matches the headline, and check it at phone width with a screen resolution tester. Many first clicks on a pre-launch link come from a phone inside a chat app.

Run the waitlist like a product, not a mailing list

A waitlist is only valuable if people remember why they joined. Treat it as an onboarding sequence that starts weeks before the product does.

• Confirm and ask one question. The confirmation email should ask what they want to use the product for. Replies are your best positioning research.
• Send progress, not hype. Short updates every two weeks: what shipped, what broke, a screenshot. Engineers respond to work, not countdowns.
• Segment by answer. Group replies by use case so the launch email can lead with the reason each person signed up.
• Let people in early, in batches. Each batch of beta users becomes a source of bug reports, quotes and launch-day comments.

Keep it legal from the first email. In the US, the FTC's CAN-SPAM compliance guide says commercial email must include a valid physical postal address, opt-out requests must be honoured within 10 business days, and "the law makes no exception for business-to-business email." If your list includes people in other countries, check their rules too; consent requirements are stricter in many places.

Three waitlist emails to write before you collect a single address

Most waitlists fail because nobody planned what to send. Write these three before the signup form goes live. The structures below are our advice, not a formula; keep each email short enough to read on a phone.

1. The confirmation email (sent instantly). Subject: You're on the list for [product]: one quick question. Body: one sentence restating the promise from the page ("early access in batches, starting in about six weeks"), then a single question: "What would you use [product] for? Just hit reply." Sign it with a real name and a reply-to address that a founder reads. No logo banner, no social icons. The goal is a reply, and replies are both positioning research and a signal to mailbox providers that people want your mail.

2. The progress update (every two weeks). Subject: something specific, such as We cut the YAML config; here's why. Body: what shipped, one screenshot or terminal snippet, one thing that didn't work, and one question for readers. Three short sections, under 250 words. Engineers forward this kind of email to colleagues; nobody forwards a countdown.

3. The beta invite (per batch). Subject: Your early access to [product] is ready. Body: the one workflow you want them to try, the exact first command or URL, how long it should take, and where to report problems. End with the ask that matters for launch: "If it's useful, would you be up for sharing how you use it when we launch publicly?" Ask for honest comments, never for votes; channel rules covered below forbid that.

Turn beta users into launch-day voices

The people who will comment on launch day are the people who used the product before it, and they need to know when and where it's happening. Keep a simple list of beta users who said yes to sharing, note which use case each one has, and send them a short note the day before launch with the link to where you'll post and a line on what's new since they joined. Ask permission before quoting anyone on the launch page, and quote them exactly. A real quote with a name and a GitHub handle is worth more than a logo wall of companies whose employees once signed up.

Get the waitlist into inboxes

A warm list is useless if the launch email lands in spam. Pre-launch is the cheapest time to fix deliverability, because your volume is low and nothing is urgent yet.

Gmail publishes the rules. Its email sender guidelines require every sender to personal Gmail accounts to set up SPF or DKIM and keep the spam rate reported in Postmaster Tools below 0.3%. Senders of 5,000 or more messages a day must set up SPF and DKIM and DMARC, and their marketing and subscribed messages must support one-click unsubscribe. Google recommends staying below a 0.1% spam rate. Most pre-launch lists are far under 5,000 a day, but a launch email to a big list can cross that line in one send, so set up all three records now.

Practical setup, as advice:

• Send from your own domain, not a free mailbox, and use the same domain as the product so the name in the inbox matches the page people signed up on.
• Authenticate before the first email. Add SPF, DKIM and a DMARC record (a p=none policy is fine to start) through your email provider's setup guide, then check the headers of a test message to see that each one passes.
• Keep the confirmation plain. A text-first email with one question gets replies, and replies help more than design.
• Remove people who never open. If someone ignores four updates in a row, ask once whether they still want to hear from you, then drop them. A smaller list that reads your mail beats a larger one that marks it as spam.
• Don't send the launch email cold. If the list has heard nothing for weeks, send a normal update a few days before launch so the launch email isn't the first thing in a month.

Publish content that's useful before the product is

The strongest pre-launch strategy for a developer tool is content about the problem, written by the people solving it. It ranks, it gets shared in communities that ban promotion, and it shows readers how you think.

The example angles above are prompts, not data; write about problems you've measured yourself. Publish on your own domain first and syndicate afterwards, so links and search credit build up where your product will live. If you write in Markdown, a Markdown to HTML converter helps when a platform only accepts HTML, and a code to image tool makes snippets shareable on social.

Free utilities deserve special mention. A small, genuinely useful tool can be launched on its own, gets linked from forums and docs, and gives you an audience of exactly the people your main product is for. You can browse free developer tools for a sense of what a focused utility looks like.

Prepare launch channels before you need them

Each launch channel has rules that shape pre-launch work. Read them now, not the night before.

The Show HN rule is the one that most changes plans. If Hacker News matters to you, the pre-launch roadmap needs a public sandbox, demo account or open-source repo, not just a signup form.

Metrics that tell you pre-launch is working

Vanity numbers are easy to grow before launch. These are harder, and more honest:

How to calculate them

Write the definitions down before you have data, so you can't redefine success after the fact. These are the formulas we suggest:

• Qualified signup rate = signups ÷ visitors from sources you chose on purpose (a community post, a newsletter, search). Exclude your own team and traffic from generic aggregators.
• Reply rate = people who replied to the confirmation question ÷ confirmation emails delivered.
• Beta activation rate = beta invitees who reached the first useful result (one completed run, one successful sync, one generated report) ÷ invitees who signed in. Define "first useful result" as a single event you can log.
• Launch-day supporters = beta users who said yes to sharing their experience publicly. A count, not a percentage.
• Content-assisted signups = signups whose first visit landed on a content page rather than the home page.

Review them weekly in a five-line note to yourself. The trend matters more than any single number, and small lists make percentages jumpy.

If signups are high but replies and beta activation are low, the page is over-promising. Fix the message before launch, not after.

A worked example: six weeks of pre-launch for a CLI tool

Here's how the pieces fit together for a hypothetical product: a command-line tool that cleans up noisy CI logs, built by two engineers. The timing and tasks are an illustration of the advice above, not a benchmark, and the right length depends on how much of the product already works. For the launch-week tasks themselves, see the product launch checklist.

Notice what the plan doesn't include: a countdown timer, a referral leaderboard or paid ads. Each week produces something a developer can read or use, and each one tests a single assumption. If week 4's activation rate is poor, weeks 5 and 6 become onboarding work, and the launch date moves; that's the plan working, not failing.

The same arc shows up in big launches. GitHub announced Copilot on June 29, 2021 as a technical preview with a limited number of spots and a sign-up. When it became generally available on June 21, 2022, at $10 a month or $100 a year, GitHub said more than 1.2 million developers had used the preview over the previous 12 months. Few products get that kind of demand, but the shape is the one to copy: limited early access, a long feedback loop, then a launch to people who already know the product.

Pre-launch mistakes to avoid

• Hiding the product. A teaser with no screenshot or demo gets curiosity clicks, not committed users.
• Collecting emails you never use. A list that hears nothing for three months forgets it signed up.
• Buying or scraping lists. It damages deliverability and trust, and may break email law.
• Launching the waitlist page as if it were the product. Channels that require something to try will reject or ignore it.
• Running pre-launch for too long. If the product slips repeatedly, ship a smaller version and keep the list warm with real access.

FAQ

What is a pre-launch marketing strategy?

It's the plan for everything you do before a product is publicly available to make sure a specific audience is ready to try it on launch day: a pre-launch website, a waitlist, useful content, a beta group and preparation for launch channels.

What should a pre-launch website include?

A headline naming the user and problem, real proof the product exists (a screenshot or short clip), an email-only signup with a clear promise, a reason to join now, and the names of the people building it. Add a title, meta description and social preview image.

Should my pre-launch page be indexed by Google?

Usually yes, so your domain starts building search presence early. Keep staging sites out with noindex or password protection; Google says robots.txt is not a mechanism for keeping a page out of its index.

Do email rules apply to a B2B waitlist?

In the US, yes. The FTC says CAN-SPAM makes no exception for business-to-business email: include a valid postal address and honour opt-outs within 10 business days. Other countries have their own, often stricter, consent rules.

Can I post my waitlist page on Show HN?

No. Show HN requires something people can try, and its guidelines treat sign-up and landing pages as off topic. Post on Show HN once there's a working demo, sandbox or repo.

How long should pre-launch marketing run?

Long enough to validate the message and build a warm list, often several weeks. If the product keeps slipping, ship a smaller version rather than stretching pre-launch for months.

Before launch, you're not collecting attention; you're collecting the people who will show up on day zero.