# The Complete Product Launch Checklist for Bootstrapped Makers > A product launch checklist for bootstrapped makers covering positioning, testing, legal basics, technical readiness, listings, venue rules, and launch day. - Canonical: https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers - Published: 2026-10-14 - Updated: 2026-10-18 - Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised) - Publisher: ZeroRaised (https://zeroraised.com/) - Section: Growth - Tags: launch-checklist, launch-strategy, bootstrapping A product launch checklist for bootstrapped makers should cover the release definition, positioning, product path, trust, technical readiness, launch materials, venue rules, support and follow-up. Work through those checks before choosing a date, because a ranking cannot repair a broken sign-up, an unclear promise or a product that the venue's audience cannot use. **TL;DR:** Decide what is actually shipping and who it is for. Test the product from a fresh account, prepare one evidence pack, adapt the post to each venue, stay available for support, and judge the release by useful product actions rather than attention alone. This guide is the long-form companion to the free [launch checklist tool](https://zeroraised.com/tools/launch-checklist), which saves progress in the browser. Use the tool to track the work and this guide to understand each check. On [17 Oct 2026, the maker using the handle celphase posted a working duck audio synthesiser as a Show HN](https://news.ycombinator.com/item?id=50131006). The small, specific submission is a useful reminder for bootstrapped makers: a launch does not require a grand claim, but the product must be accessible, understandable and ready for strangers to try. This guide is for products built without institutional VC or accelerator equity. [ZeroRaised](https://zeroraised.com/) is a launch and discovery site for those makers, the current [submission route is here](https://zeroraised.com/submit), and members can review the available [perks](https://zeroraised.com/perks). This article makes no promise about audience size, placement or results. ## Product launch checklist for bootstrapped makers Before doing any promotional work, write a short launch brief. Name what becomes available, the specific user and job, the proof a visitor can verify, the action that would make the release useful, and the support constraint. The objective should describe behaviour, not applause. “A new user completes an import and sees a useful result” guides onboarding work. “Get attention” does not. If the release is intended to validate demand rather than distribute a finished product, use the [SaaS validation guide](https://zeroraised.com/blog/how-to-validate-a-saas-idea-before-building) first. If the problem is already validated but the audience is still empty, pair this checklist with the [bootstrapped app launch guide](https://zeroraised.com/blog/how-to-launch-a-bootstrapped-app). ### Classify the release before choosing a venue A first public release, a private beta, a significant product update and a listing in a software directory are different pieces of work. The distinction matters because venues apply different eligibility rules. Show HN asks people to submit something they made that others can try, excludes sign-up pages, and says ordinary feature updates are usually insufficient, although a major overhaul may qualify ([Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026). Product Hunt asks makers to wait at least [six months between posts for the same product or company](https://help.producthunt.com/en/articles/484934-can-i-relaunch-my-product) and requires a significant update, checked 18 Oct 2026. | Release state | Best immediate job | Suitable starting point | Common mismatch | |---|---|---|---| | Waitlist or invitation queue | Learn whether the promise attracts the intended user | BetaList accepts eligible unreleased and private-beta startups ([criteria](https://betalist.com/criteria), checked 18 Oct 2026) | Show HN excludes sign-up pages, and Product Hunt does not feature waitlisted products without immediate access ([Show HN](https://news.ycombinator.com/showhn.html), [Product Hunt](https://help.producthunt.com/en/articles/9883485-product-hunt-featuring-guidelines), checked 18 Oct 2026) | | Usable first public release | Observe onboarding, use and questions | A specialist community, Product Hunt, or Show HN when the product and audience fit their rules | Posting where the intended user has no reason to evaluate the product | | Major rebuild | Explain what materially changed and invite previous users back | A relaunch where venue rules permit it, plus your own opted-in audience | Treating a new colour, price or headline as a new product | | Released product seeking durable discovery | Create an accurate category listing | SaaSHub accepts released software and rejects waiting-list pages ([submission rules](https://www.saashub.com/services/submit), checked 18 Oct 2026) | Expecting a directory profile to behave like a discussion-led release | Read the full [stage-based guide to where to launch a SaaS](https://zeroraised.com/blog/where-to-launch-a-saas) when the main uncertainty is venue choice. ## Fix the positioning before polishing assets - [ ] Write one sentence in this form: “For [specific user] who needs [job], [product] helps them [observable result] by [credible mechanism].” - [ ] Remove any adjective that a visitor cannot verify from the page or product. - [ ] Name the alternative honestly. It may be a spreadsheet, a manual process or doing nothing, not merely a rival product. - [ ] Put access conditions near the main action. Say whether the product requires payment, an invitation, an account, a download or a particular device. Use the customer's vocabulary in the title and main heading. Google advises site owners to use words people would use to look for the content and place them in prominent locations such as the title and main heading ([Google Search Essentials](https://developers.google.com/search/docs/essentials), checked 18 Oct 2026). That is useful beyond search: familiar words reduce the effort required to understand a launch card. Real listings make the difference clear. NitroStack describes itself as “Build, test, and deploy MCP servers in one place” on its [Product Hunt product page](https://www.producthunt.com/products/nitrostack), checked 18 Oct 2026. It names actions, an artefact and a scope. A line such as “the future of intelligent development” would communicate none of those things. Likewise, the duck synthesiser in the opening hook tells a reader exactly what can be tried before the click. These are examples of specificity, not evidence that either wording guarantees a result. ## Test the complete product path as a stranger Do not rely only on an old account with seeded data, saved credentials and browser permissions already granted. A release visitor may have none of that context. Test the path from a clean browser profile and use realistic, non-sensitive sample data. ### Arrival and access - [ ] Open every URL you plan to share. Confirm that redirects arrive on the intended canonical page and preserve campaign parameters. - [ ] Follow the path without using an admin account, stored session or password manager entry. - [ ] Create a fresh account. Verify the address, sign out, sign in and request a password reset. - [ ] Confirm that invitation, region, platform and browser limits are visible before a visitor gives personal information. - [ ] If a person can try the useful part without an account, link straight to it. Show HN explicitly recommends easy access, ideally without sign-up or email barriers ([Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026). ### First useful result - [ ] Define the first result in one sentence. “The user sees the dashboard” is navigation; “the user imports a file and finds the missing records” is a result. - [ ] Complete that action with an empty account and no sample state. - [ ] Check that permissions are requested at the moment their purpose is clear. Explain why a browser, repository, calendar or payment permission is needed. - [ ] Verify that emails arrive, their links point to the correct environment, and replies reach a monitored address. ### Failure and recovery - [ ] Submit an empty form, invalid input, an expired link and a duplicate record. - [ ] Reach a plan limit and a payment failure deliberately. The message should say what happened without erasing work. - [ ] Use the support route as a visitor. Confirm that it reaches the person handling the release. Keep a defect log with the path, expected and observed behaviour, severity and owner. Fix anything that blocks access or the first useful result before adding launch venues. If the product was built quickly with generated code, add the checks in the [vibe-coded app security checklist](https://zeroraised.com/blog/vibe-coded-app-security-checklist). If it is a browser add-on, the [Chrome extension launch guide](https://zeroraised.com/blog/how-to-launch-a-chrome-extension) covers store-specific review and permission work. ## Cover trust, privacy and accessibility This section is operational preparation, not legal advice. Requirements vary by location, product and customer, so obtain qualified advice when the risk warrants it. - [ ] Publish a privacy notice that accurately describes the data collected, its purpose, retention, service providers and contact route. - [ ] Publish terms that match the product sold, including billing, cancellation and refund conditions where relevant. - [ ] Identify the maker or business in a way appropriate to the product, and provide a working support contact. - [ ] Remove customer logos, testimonials and outcome claims unless you have permission and can support the exact wording. For United Kingdom recipients, the Information Commissioner's Office says organisations must not send marketing email or text to individuals without specific consent, apart from a limited exception for their own previous customers. It also requires a valid contact address for opting out, and says the rule covers social direct messages and similar stored electronic messages ([ICO electronic mail guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/), checked 18 Oct 2026). Do not turn an old support list, scraped directory or unrelated sign-up list into a release mailing list. Accessibility testing belongs in the release path, not in a later polish queue. The W3C describes WCAG 2.2 as recommendations for making web content more accessible across disabilities and devices ([WCAG 2.2](https://www.w3.org/TR/WCAG22/), checked 18 Oct 2026). For a practical pass: - [ ] Navigate the landing page, account creation and main task using only a keyboard. - [ ] Confirm that focus is visible and follows a sensible order. - [ ] Give every form control a programmatic label and associate error text with the relevant field. - [ ] Add useful text alternatives to informative images, check contrast and enlarged text, and provide captions or motion controls where they apply. - [ ] Do not rely on colour alone to communicate status, price tier or validation. ## Make the launch surface technically ready ### Performance and resilience - [ ] Measure the release page and the first authenticated screen on mobile and desktop. - [ ] Reserve image dimensions, compress large media and defer non-essential third-party scripts. - [ ] Configure error reporting, uptime checks and alerts that reach the person on support. - [ ] Review hosting, database, [email sending](https://zeroraised.com/data/email-tiers), storage and third-party API limits. Write down the safe response if any limit is reached. Philip Walton's Web Vitals guide gives the current “good” thresholds as [Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less](https://web.dev/articles/vitals), assessed at the 75th percentile, checked 18 Oct 2026. Those figures are diagnostic targets, not a substitute for completing the real workflow on a representative device. ### Sharing and search - [ ] Use one canonical public URL for the product and redirect accidental variants to it. - [ ] Add and test `og:title`, `og:type`, `og:image` and `og:url`, the [four properties required by the Open Graph protocol](https://ogp.me/), checked 18 Oct 2026. Add a useful image alternative and description. - [ ] Paste the exact URL into the networks and messaging apps you plan to use. Inspect the fetched title, image and description rather than trusting a local preview. - [ ] Remove any staging `noindex`, blocked route or password gate from pages meant to be public. - [ ] Link the product page through ordinary crawlable links and include it in the sitemap. Google lists crawlable links among its technical requirements and recommends using words people search for in titles, headings and link text ([Search Essentials](https://developers.google.com/search/docs/essentials), checked 18 Oct 2026). - [ ] Add structured data only when it accurately describes visible page content. Google says markup must represent the page and must not describe content hidden from users ([structured data guidance](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data), checked 18 Oct 2026). ## Build one evidence pack Prepare a source folder and a plain-text launch brief. This prevents rushed copy from drifting across profiles. - [ ] Canonical product name, URL, maker identity and contact details. - [ ] The positioning sentence, a factual description and an explanation of what changed. - [ ] The narrowest accurate category, plus current access, platform, region, price and plan limits. - [ ] A square logo, a clear interface image and a social preview image. - [ ] A short product demonstration when motion or sequence explains the value better than a still image. - [ ] Evidence for customer quotes, comparisons, compatibility claims and eligibility statements. - [ ] A disclosure sentence that makes your relationship to the product obvious. Use real product data that is safe to expose, or obviously labelled sample data. Do not fill an interface with impossible revenue, fabricated customers or a feature that is still on a private branch. The asset pack should document the release people will actually receive. A demonstration should show one meaningful path: starting state, user action and result. Avoid a rapid tour of every menu. The [product demo video guide](https://zeroraised.com/blog/how-to-make-a-product-demo-video) covers the script, capture and edit in more depth. Store a source next to every factual statement that may change. If a plan, integration or platform changes before release, you can find and correct the screenshots, page copy and listings together. ## Choose venues by access, audience and objective Do not begin with a giant directory spreadsheet. Shortlist venues whose eligibility, audience and format match the release, then read their current rules from the source. | Venue | Use it when | Do not use it when | First-party rule to recheck | |---|---|---|---| | Show HN | People can try work you made, and you can explain how and why | You have only a landing page, newsletter, fundraiser or sign-up form | [Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026 | | Product Hunt | The product gives immediate access and the intended user overlaps its product-discovery audience | The page is only a waitlist, or the category is excluded from featuring | [How Product Hunt works](https://www.producthunt.com/launch/how-product-hunt-works) and [featuring guidance](https://help.producthunt.com/en/articles/9883485-product-hunt-featuring-guidelines), checked 18 Oct 2026 | | BetaList | An eligible technology startup is unreleased, invitation-only or recently released | The submission is a blog, course, agency or generic template page | [BetaList criteria](https://betalist.com/criteria), checked 18 Oct 2026 | | DevHunt | Developers are the product's intended users | It is not a developer tool, or it sells fake engagement | [DevHunt questions](https://devhunt.org/faq), checked 18 Oct 2026 | | SaaSHub | Released software has its own suitable product site | The product is unreleased, uses a waiting-list page or sits on a free subdomain | [SaaSHub submission rules](https://www.saashub.com/services/submit), checked 18 Oct 2026 | | ZeroRaised | The product and maker satisfy the current bootstrapped eligibility and submission requirements | The product does not meet the published requirements | [ZeroRaised submission](https://zeroraised.com/submit), checked 18 Oct 2026 | Product Hunt says homepage order considers engagement and time since submission, rather than simply displaying the visible vote count ([How Product Hunt works](https://www.producthunt.com/launch/how-product-hunt-works), checked 18 Oct 2026). Because time on the board counts, [check when the Product Hunt day starts in your time zone](https://zeroraised.com/tools/launch-time) before you choose an hour. Show HN sends submissions to `shownew`, with qualifying posts later appearing on its Show page ([Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026). Prepare a product card for one and a maker-led technical discussion for the other. Use the [Product Hunt alternatives guide](https://zeroraised.com/blog/product-hunt-alternatives-for-bootstrapped-makers) for a broader shortlist, or compare [Product Hunt and Show HN](https://zeroraised.com/blog/product-hunt-vs-show-hn) directly. A long venue list is useful only after it has been filtered by fit. ## Write a post that belongs on the venue Start from the same facts but rewrite the opening for the context. A community post should contribute an explanation or lesson. A directory entry should be stable and literal. A launch card should communicate the product and release at a glance. - [ ] Use the real product name and a plain description. - [ ] State that you made the product. - [ ] Explain why it exists, what changed and what kind of feedback would help. - [ ] Link to the page that best matches the post, not automatically to the home page. - [ ] Describe price and access accurately. - [ ] Remove unsupported superlatives, fake urgency and comparisons you have not tested. - [ ] Read the text in the venue preview and on a phone before submitting. - [ ] Write replies in your own voice and answer the question asked. Hacker News tells submitters not to make titles stand out with uppercase or exclamation marks, not to solicit votes or comments, and not to put generated text in posts ([Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html), checked 18 Oct 2026). Show HN also asks makers to explain how and why they built the project and remain available for discussion ([Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026). For a technical audience, describe one difficult decision and its trade-off. For a buyer audience, show the job, access conditions and result. For a directory, use durable category language that will still be correct after release week. Do not paste the same introduction everywhere and call it tailored. If Product Hunt is on the plan, use the detailed [Product Hunt launch guide](https://zeroraised.com/blog/how-to-launch-on-product-hunt). If the product fits Hacker News, use the [Show HN writing guide](https://zeroraised.com/blog/how-to-write-a-show-hn-post). ## Run a release rehearsal Schedule a rehearsal before public posting. Use the production system and ask a person who did not build the feature to follow the same link a visitor will receive. - [ ] Freeze the exact URL, copy and assets for review. - [ ] Open each destination while signed out. - [ ] Complete account creation, the main workflow and any payment path. - [ ] Trigger a failure and use the recovery route. - [ ] Send the announcement to an internal test address and inspect it on a phone. - [ ] Confirm that source attribution reaches the analytics or event log you actually inspect. - [ ] Prepare a plain incident message that states the affected function, what users should do and where updates will appear. - [ ] Decide who can pause promotion, disable a broken feature or revert the release. Keep promotion reversible. Move a scheduled post if the main path is unreliable. ## Treat release day as support work The maker's most useful role during the release is to observe, answer and repair. Keep the product, error logs, support inbox and venue discussion available, but avoid making several unrelated changes while trying to interpret user behaviour. - [ ] Test the public link once more from a signed-out browser before posting. - [ ] Publish the correct disclosure and access conditions. - [ ] Answer questions factually. If you do not know, say what you will check. - [ ] Record repeated confusion in the defect log instead of debating the user. - [ ] Separate access failures, usability friction, feature requests and objections. - [ ] Post a concise status update when something breaks, then confirm when it is repaired. - [ ] Stop promotion if the core path risks user data, payment or account access. - [ ] Thank people for useful reports without asking them to vote, comment or review. Hacker News prohibits soliciting votes, comments or submissions, and Show HN repeats that makers should not ask friends to vote or comment ([Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html), [Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026). Product Hunt says makers found spamming audiences or paying for votes can have the product removed ([How Product Hunt works](https://www.producthunt.com/launch/how-product-hunt-works), checked 18 Oct 2026). Share the existence of a release where appropriate, but do not prescribe engagement. ## Turn the response into product decisions Capture evidence while it is fresh, then wait long enough for users to attempt the product. Review the result by source and by stage in the user path. ### Immediately after the active discussion - [ ] Save the permanent listing and discussion URLs. - [ ] Export or record errors, support requests and source attribution before logs roll over. - [ ] Correct any public listing whose price, access or description is wrong. - [ ] Send promised follow-ups to people who reported defects. - [ ] Write down what changed during the release so later analysis is not based on memory. ### After users have had time to try the product - [ ] Compare sources by the objective in the brief, not by visits alone. - [ ] Find the largest drop before the first useful result and inspect the sessions or reports behind it. - [ ] Group feedback into defects, unclear communication, missing capability and audience mismatch. - [ ] Give repeated observed problems priority over isolated feature suggestions. - [ ] Ask people who stopped what they expected and where that expectation came from. - [ ] Record the money and maker time spent on each venue. ### Before another release - [ ] Update the product page, onboarding and evidence pack with what was learned. - [ ] Return to the channel that produced relevant use or useful conversations. - [ ] Remove channels that created support cost without reaching the intended user. - [ ] Set a clear threshold for a relaunch based on a material product or access change. - [ ] Recheck every platform rule rather than copying the previous plan. Product Hunt's current relaunch guidance asks makers to wait at least [six months and make a significant product update](https://help.producthunt.com/en/articles/484934-can-i-relaunch-my-product), checked 18 Oct 2026. It gives examples such as a new mobile app or a complete redesign with new functionality, while saying a new interface or pricing change is not significant. Show HN similarly says routine new features and upgrades are generally insufficient, although a major overhaul may qualify ([Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026). For work after the release, the [first users guide](https://zeroraised.com/blog/how-to-get-your-first-100-users) covers conversations, activation and repeatable acquisition. Treat any named user count in that article as its topic, not as a universal milestone every product must pursue. ## Where ZeroRaised fits ZeroRaised is a launch and discovery site for bootstrapped indie makers whose products have no institutional VC or accelerator equity. Review the current requirements and submit through [the product form](https://zeroraised.com/submit). The [member perks page](https://zeroraised.com/perks) lists the offers currently available to eligible members. Use ZeroRaised as one part of a plan, not as a replacement for talking to the people with the problem. The same evidence pack, truthful disclosure, tested onboarding and source attribution apply here as they do elsewhere. No listing can supply product-market evidence on its own. ## Sources checked for this rewrite - [Hacker News, Show HN guidance](https://news.ycombinator.com/showhn.html), checked 18 Oct 2026 - [Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html), checked 18 Oct 2026 - [Hacker News hook submission](https://news.ycombinator.com/item?id=50131006), checked 18 Oct 2026 - [Product Hunt, how the platform works](https://www.producthunt.com/launch/how-product-hunt-works), checked 18 Oct 2026 - [Product Hunt featuring guidance](https://help.producthunt.com/en/articles/9883485-product-hunt-featuring-guidelines), checked 18 Oct 2026 - [Product Hunt relaunch guidance](https://help.producthunt.com/en/articles/484934-can-i-relaunch-my-product), checked 18 Oct 2026 - [NitroStack on Product Hunt](https://www.producthunt.com/products/nitrostack), checked 18 Oct 2026 - [BetaList submission criteria](https://betalist.com/criteria), checked 18 Oct 2026 - [SaaSHub submission rules](https://www.saashub.com/services/submit), checked 18 Oct 2026 - [DevHunt questions](https://devhunt.org/faq), checked 18 Oct 2026 - [Google Search Essentials](https://developers.google.com/search/docs/essentials), checked 18 Oct 2026 - [Google structured data guidance](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data), checked 18 Oct 2026 - [Philip Walton, Web Vitals](https://web.dev/articles/vitals), checked 18 Oct 2026 - [The Open Graph protocol](https://ogp.me/), checked 18 Oct 2026 - [W3C Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/), checked 18 Oct 2026 - [ICO electronic mail marketing guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/), checked 18 Oct 2026 ## Frequently asked questions ### How early should a bootstrapped maker start launch preparation? Start while there is still time to repair onboarding, billing, access and product-page problems. Copy and image work can come after the complete user path is reliable. ### Can a waitlist page be submitted to launch platforms? It depends on the venue. BetaList accepts eligible pre-launch startups, while Show HN requires something people can try and Product Hunt does not feature a waitlisted product without immediate access. ### Should a maker post on every launch platform at once? Usually no. Spacing posts gives one maker time to answer questions, repair friction and identify which venue sent useful users. ### What should be measured after release? Measure the action tied to the launch objective, such as completed onboarding, a useful workflow, a qualified conversation or a purchase, and separate it by source. ### When is a relaunch justified? Relaunch when the product or its access has changed substantially enough to give returning visitors a genuinely different experience, and only where the venue's current rules allow it.