Indie SaaS Pre-Launch Strategy: Win Before You Ship Product
Pre-launch is not a countdown timer on a landing page. It is the work you do to make sure the right people feel a problem acutely—and trust you to solve it—before billing goes live. Solo founders lose here by copying enterprise playbooks: webinars, nurture sequences, partner ecosystems. You need a strategy that fits one person, a static site, and maybe twenty hours a week. This guide sequences positioning, audience, channels, and milestones so your launch is a continuation of conversations, not a cold start.
Define a narrow beachhead
Pre-launch marketing fails when the message speaks to everyone. Pick a beachhead: one role, one workflow, one acute pain. "Project management for teams" is a graveyard. "Standup notes that sync to Linear for remote eng leads" is a door. Your static landing page headline should make that beachhead nod, not scroll past.
Write a positioning memo in 200 words: problem, alternative (spreadsheets, status quo), differentiated approach, proof you can deliver (your background, prototype screenshot, design partner quotes). Every tweet, DM, and FAQ answer should trace back to this memo. When you are tempted to add a feature bullet for a different persona, update the memo first or say no.
- Beachhead user described with job title and weekly workflow
- Top three alternatives listed honestly—not strawmen
- One metric users care about (time, errors, revenue, stress)
- Reason to believe: demo GIF, testimonial, or your credible story
- Explicit non-goals: who this is not for
Stages of pre-launch
| Stage | Goal | Primary asset |
|---|---|---|
| Problem validation | Confirm pain in their words | Interviews + community posts |
| Waitlist | Capture intent and emails | Static landing + form |
| Nurture | Stay top of mind without spam | Email every 1–2 weeks |
| Beta | 5–15 users on real workflow | Manual onboarding doc |
| Launch | Convert waitlist + public push | Pricing page + changelog |
Do not skip to paid ads before Problem validation. Ads amplify message; they do not invent fit. Two weeks of conversations in one subreddit or Slack often beats $500 in Meta spend with vague copy.
Build in public without building noise
Build in public works when you share decisions, metrics, and lessons—not repository commit counts. Post weekly: what you learned from users, what you cut from scope, what surprised you. Pair every post with a link to your waitlist only when the post delivers value standalone. Followers reward honesty about failures; they ignore "Day 47 of coding my startup."
- Monday: ship one visible improvement (copy, screenshot, micro-demo)
- Wednesday: ask one question your beachhead would debate
- Friday: share a number—signups, churn risk, time saved in beta
- Keep a swipe file of verbatim user phrases; reuse in landing copy
- Reply to every waitlist signup within 24 hours early on—it sets tone
Channel selection for one person
Pick two channels maximum until waitlist hits 200. Channel fit beats channel hype. B2B dev tools: X, Hacker News Show HN, niche Discords. Local SMB SaaS: Facebook groups, chambers, cold email with Loom. Creator tools: YouTube shorts, TikTok demos. Go where you already have reputation hours—not where a guru said you must be.
- Owned: landing page, email list, changelog on static site
- Earned: guest posts, podcast spots, community answers with depth
- Rented: X, LinkedIn, Reddit—algorithm changes; capture emails always
- Paid: retargeting waitlist visitors later; cold paid after message converts organically
Waitlist as a product, not a email dump
Treat waitlist subscribers as early members. On signup, send immediate confirmation with what happens next and when. Segment by signup source (footer CTA vs blog post vs referral) using hidden form fields or UTM parameters stored in your spreadsheet. First nurture email within three days: story behind the product, not "10% off coming soon."
Offer one lightweight reward for engagement: template, audit checklist, or office hours slot for the first 50. Rewards should filter for serious users, not coupon hunters. A PDF that helps with the problem—even if your tool is not built yet—builds trust.
Content cadence on a static site
You do not need a daily blog. You need three durable pages: landing, one deep guide that ranks for a long-tail problem, and changelog or roadmap. Add posts when you have data or a story—not to satisfy an editorial calendar ghost. Static generators make adding /blog/my-lesson.html cheap; silence is better than filler.
- Landing page CTA above fold on mobile
- One guide targets a specific search intent your user has pre-purchase
- Changelog shows momentum dates even if entries are small
- Internal links from guide to waitlist with contextual CTA
- Author bio or about page explains why you are credible
Design partners before scale
Recruit five to ten design partners from waitlist volunteers who match the beachhead. Offer free lifetime tier or heavy discount in exchange for weekly 30-minute feedback and permission to quote them. Their language becomes your homepage. Their blockers become your sprint. Launch day testimonials write themselves if you did this work.
Say no to partners outside the beachhead. A friendly enterprise IT director will pull your roadmap toward SSO and audit logs before you have ten users. Politely decline or park them on a separate list.
Metrics that matter pre-revenue
- Waitlist signups per week by source
- Landing conversion rate by channel (do not blend)
- Email open and click rates on nurture sequence
- Design partner completion of key workflow tasks
- Unsolicited referrals or "when can I pay" messages
Vanity follower counts lag revenue. Signups and replies are leading indicators. If signups stall for three weeks while you build features, stop coding and fix distribution or positioning.
Pre-launch email sequence (five emails)
- Day 0: Welcome—what you are building, timeline honesty, reply invitation
- Day 3: Problem story—your origin or a user story with permission
- Day 10: Behind the scenes—screenshot or Loom of current state
- Day 17: Ask—one multiple-choice question about priority feature
- Day 24: Beta invite or launch date with clear next step
Keep emails plain text or minimal HTML. No heavy images that trip spam filters. One link per email. Unsubscribe link is non-negotiable for trust and compliance.
Launch week coordination
Pick a Tuesday–Thursday launch day; avoid major holidays and US three-day weekends. Queue Show HN, Product Hunt, email blast, and social threads within the same four-hour window so momentum compounds. Prepare support: FAQ updated, inbox monitored, known bugs listed honestly on changelog. Sleep the night before—launch day is support and storytelling, not deploying auth.
Mistakes solo founders repeat
- Launching product before landing page converts warm traffic
- Collecting emails without permission to contact or clear value
- Promising dates you miss—under-promise by weeks
- Competing on features against incumbents instead of wedge workflow
- Ignoring churn from waitlist unsubscribes as a messaging signal
- Building referral mechanics before base offer is clear
Static-site tactics that compound
Add a /roadmap page with three columns: now, next, later. Public roadmaps reduce "when will you build X" emails and attract users who want transparency. Use /changelog for weekly bullets—even copy tweaks show velocity. Link both from footer and nurture emails. When you graduate to app, keep marketing static for speed; app subdomain for product.
Pre-launch ends when strangers pay or actively use beta without hand-holding. Until then, your job is conversations at scale your sanity allows. The static landing page is the hub; everything else is spokes you maintain deliberately.
Budget and timeboxing
Solo pre-launch marketing should fit a realistic weekly budget: five to ten hours and under $100/month until conversion proves out. Spend money on email tooling and one professional OG image before ads. Track hours in a simple spreadsheet—if you spent twelve hours on logo tweaks and zero on user calls, rebalance.
Legal and compliance basics
Waitlist pages still need privacy policy explaining what you collect and how long you keep it. CAN-SPAM and GDPR principles apply even at small list sizes: clear sender, physical or business address in footer, working unsubscribe. Do not import LinkedIn scrapes into Mailchimp. Consent-based lists convert better at launch anyway.
Competitive teardown ritual
Monthly, screenshot three competitors' landers and note headline, CTA, proof, and pricing hints. You are not copying—you are mapping table stakes versus wedge. If everyone promises "AI-powered," your wedge might be "works offline" or "setup in four minutes." Save teardowns in /docs/competitors.md in your repo for positioning debates with future cofounders or advisors.
- Capture full-page screenshot on mobile and desktop
- Write their implied beachhead in one sentence
- List what they ask for at signup
- Note what they do not say—your FAQ opportunity
- Decide one deliberate difference for your next copy pass
Community-led loops
Create a simple loop: teach in public → CTA to waitlist → welcome email asks one question → best answers become changelog or guide quotes → share update tagging contributors. Loops beat one-off viral posts because they compound trust. Static site hosts the CTA and changelog; community hosts the conversation—you bridge both.
Saying no to scope creep
Pre-launch DMs will request integrations you cannot ship before launch. Maintain a public "not yet" list on roadmap page instead of custom promises per DM. Polite template: "Great idea—logged on roadmap vote. Launching core workflow first; I'll email waitlist when [integration] ships." Consistency protects launch date and your sanity.
Record a two-minute Loom walking through the waitlist page and form once copy stabilizes. Reuse in emails when people ask what you are building—video beats paragraphs for busy founders. Keep the Loom unlisted and update quarterly so links in old threads stay accurate.
Align pre-launch messaging with support capacity. If you are solo, promise human replies within 48 hours, not live chat 24/7. Under-promising response time on the static FAQ prevents one-star tweets at launch when inbox spikes.
Batch creative work: refresh landing copy Monday, outreach Tuesday, product Wednesday, email Thursday, analytics Friday. Context switching between writing hero headlines and debugging API code in the same hour produces mediocre versions of both. Your static page deserves a focused editing block like any product feature—protect it on the calendar.
Related: Waitlist conversion playbook Waitlist templates How-to guides Free landing kit Marketing tools
How big should my waitlist be before launch?
Quality beats quantity. Fifty engaged signups from your beachhead beat 2,000 generic emails. Aim for consistent week-over-week growth and reply rates on nurture mail above 20% early on.
Should I charge before the product is ready?
Lifetime deals or refundable pre-orders work for some niches; they require clear scope and refund policy. Many solo founders launch free beta first, then convert design partners to paid—simpler legally and operationally.
Product Hunt on day one?
Only if landing page, onboarding, and support are ready for a traffic spike. Many indies do better with Show HN or community launch first, then PH when testimonials exist.
How often should I email waitlist subscribers?
Every one to two weeks during build. Increase to twice a week only the seven days before launch. Silence for a month kills interest; daily pitches feel spammy.
What if my niche community hates self-promotion?
Lead with teaching: threads, templates, teardowns. Put your link in bio and at the end after value. Ask moderators if unsure. Reputation takes longer but lasts.
Start your pre-launch hub
Pair this strategy with a conversion-focused waitlist template and ship your static pre-launch site before the next feature sprint.
Pick a template Optimize conversions