# How to Launch a Bootstrapped App With No Audience (2026) > How to launch a bootstrapped app with no audience or budget: make it tryable, find ten real users, pick one venue that fits, then follow up for 30 days. - Canonical: https://zeroraised.com/blog/how-to-launch-a-bootstrapped-app - Published: 2026-10-14 - Updated: 2026-10-17 - Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised) - Publisher: ZeroRaised (https://zeroraised.com/) - Section: Growth - Tags: bootstrapping, app-launch, launch-strategy To launch a bootstrapped app with no audience or budget, make the smallest useful version easy to try, recruit ten real users by hand, choose one venue that fits the product, and follow up for 30 days. The whole plan takes one product-preparation phase, one launch and 30 days of follow-up. This page exclusively covers the “no audience, no budget” problem. Use the [product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers) for general release readiness and the [stage-by-stage SaaS launch guide](https://zeroraised.com/blog/where-to-launch-a-saas) to choose between waitlist, beta, first-release and established-product venues. Here, the constraint is sharper: nobody is waiting for the announcement, and you cannot buy attention. **Disclosure:** [ZeroRaised](https://zeroraised.com/) publishes this guide and is itself a launch board. It makes no claim here about audience size, traffic, conversions or launch results. ## TL;DR This plan is ZeroRaised editorial advice. The venue rules in the last row come from the linked primary sources. | Phase | What to do | What to produce | Continue when | |---|---|---|---| | Product preparation | Make one useful result possible without founder explanation | A tryable product, a clear page and a tested first-use path | A new user can reach the core action from a fresh browser | | First ten users | Contact intended users individually and ask for one specific test | Ten names, permission-based messages and notes from real use | Repeated confusion is understood and the largest obstacle is fixed | | Venue choice | Compare audience, access rules, cost and the work needed to reply | One primary venue and one adapted launch post | The product qualifies and you can remain available for discussion | | Public launch | Publish once, answer questions and support attempts to use the product | A source-tagged link, a reply log and an issue list | The active conversation has slowed and urgent product failures are handled | | 30-day follow-up | Compare sources, interview users, fix one repeated problem and run the next small test | Visits, activations and conversations by source, plus a change log | You can explain what happened without relying on votes or impressions alone | Show HN requires something people can try, Product Hunt says it is free to use, DevHunt limits launches to developer tools, and BetaList accepts unreleased, private-beta and recently released technology startups ([Show HN](https://news.ycombinator.com/showhn.html), [Product Hunt](https://www.producthunt.com/launch/how-product-hunt-works), [DevHunt](https://devhunt.org/faq) and [BetaList](https://betalist.com/criteria), checked 17 Oct 2026). ## What does “no audience and no budget” mean? For this guide, **no audience** means you have no dependable group of people who have asked to hear about the release. Social followers who never requested product updates do not count toward the working launch list. This is a planning definition, not a claim about what qualifies as an audience elsewhere. **No budget** means no spending on ads, paid placement, purchased lists or launch promotion. It does not mean pretending the product has no operating costs. Hosting, a domain, email delivery, payment processing and support may still require money or a limited free plan; the [payment fee calculator](https://zeroraised.com/tools/payment-fee-calculator) shows what payment processing costs per sale. Review current vendor terms before depending on any allowance. The [maker perks page](https://zeroraised.com/perks) links to official terms for tools, credits and free tiers without turning their limits into promises. These constraints change the job. Your first goal is not to create the appearance of demand. It is to give a small number of appropriate people a clear reason to try the product, observe what they do and earn the right to ask for another conversation. That is ZeroRaised editorial advice. Set a launch objective before selecting a venue. Choose one observable result: completed core actions, qualified conversations, paid orders, useful technical feedback or sign-ups from people who match the intended user. Do not combine all five into a vague goal called “awareness.” This is also editorial advice, not a universal definition of success. ## What are the three starting assets? You need three assets before a public launch: a tryable product, one clear message and a list of ten real people who have the problem. This is a minimum working set proposed by ZeroRaised, not a platform requirement or performance benchmark. ### 1. A tryable product “Tryable” means a stranger can reach the product’s core action under the access conditions you disclose. If the product needs an invitation, sample data or a manual setup step, say so before the person commits time. If you plan to use Show HN, the standard is stricter: the official guidelines exclude sign-up pages and landing pages, ask for something people can try, and say that avoiding sign-up or email barriers is ideal ([Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026). Choose one core action. It might be creating the first project, importing a real record, generating a valid output or completing a transaction. Those are examples, not a universal list. Test the path from an unfamiliar browser and account. Record every instruction you had to give verbally. Each instruction is a candidate for the interface, onboarding or help text. ### 2. One clear message Write one sentence with three parts: > [Product] helps [specific user] complete [specific job] without [relevant obstacle]. Treat that structure as a drafting tool, not a slogan formula. Replace category labels such as “teams” or “creators” with the narrowest user you can actually recruit. Replace broad benefits such as “save time” with the task they want to finish. Do not claim a numerical result unless you have evidence that applies under the conditions you describe. Put the sentence above the first call to action. Follow it with a product image, short recording or sample that shows the current product. State the price, trial conditions, invitation requirement and important limitations plainly. These are editorial recommendations intended to reduce uncertainty, not claims that a particular page structure converts better. ### 3. Ten real people Build a list of ten people who plausibly experience the problem. Ten is a manageable operating target for this guide, not a research threshold and not a forecast of how many will reply. A real person is someone you can name and contact through an appropriate route. A scraped address, purchased contact or anonymous follower count is not part of this list. For each person, record why they might have the problem, where you encountered them, whether you have permission to contact them and what you will ask them to do. If you cannot name ten plausible people, pause the public launch. Narrow the user definition or return to problem research before trying to solve distribution with a larger venue. ## How do you make the app easy for a stranger to try? The following checklist is ZeroRaised editorial advice. It is deliberately shorter than the full [bootstrapped product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers). - Open the product in a fresh browser profile and complete the first useful action. - Test account creation, sign-in, password reset and sign-out if the product uses accounts. - Test the empty state. A new user should know what to add, import or create first. - Provide safe sample data when the product is hard to understand from a blank screen. - Show the access condition before the main call to action: open access, invitation, trial, paid account or demonstration. - Put a working support route where a new user can find it. - Prepare a plain status message for a launch-related failure. - Remove claims, screenshots and pricing that no longer match the product. - Record the source of each launch link with a distinct parameter or short path. Do one five-minute comprehension test before asking for full use. Show the page to an intended user without explaining it, then ask: “Who is this for, what does it do, and what would you click next?” Do not correct the person during the test. Rewrite the page if their answer differs from the intended message. This is a qualitative test suggested by ZeroRaised, not a validated conversion experiment. Do not hide product limitations from the first testers. If an export is manual, an integration is incomplete or data will be deleted after a test, disclose that before the user relies on the feature. The purpose of the private phase is to discover whether the product and promise agree. ## How do you find ten users when nobody follows you? Start with access you already have, then move outward one relationship at a time. This sequence is editorial advice: 1. List people you know personally who match the intended user. Do not include supportive friends who do not have the problem. 2. Ask each appropriate contact for a small test, not a generic opinion. 3. Ask a user who completed the test whether one other person has the same problem. Make the introduction optional. 4. Read public discussions where the problem is already being described. Contribute only where the rules allow it and where your reply answers the current question. 5. Contact a relevant community owner before posting if the self-promotion rule is unclear. A useful request names the reason, the task and the time boundary. For example: > You mentioned that reconciling contractor invoices takes several passes. I built a small tool for that workflow. Would you be willing to try importing one non-sensitive example and tell me where the process becomes unclear? No need to post about it. If it is irrelevant, a no is completely fine. That message is an example, not a template to send in bulk. Personalize the problem and requested action. Do not ask someone to create promotional content, vote or recruit others as the price of access. During each test, record what the person attempted, where they paused, what they expected and whether they completed the core action. Separate observation from interpretation. “Clicked pricing before starting” is an observation. “The page needs cheaper pricing” is an interpretation that requires more evidence. ## Which launch venue fits a bootstrapped app with no audience? Pick a venue after the product and first ten users, not before. The best fit depends on who the product serves, whether people can use it now and whether the venue accepts that type of submission. The cost and rule statements below come from each venue’s own pages. | Venue | Best fit | Cost | Key rule | Primary source | |---|---|---|---|---| | Show HN | A substantive product the maker worked on and can discuss, with access for HN users to try it | No submission fee is stated in the guidelines | The title begins with `Show HN`; sign-up pages, landing pages and work people cannot try are excluded | [Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026 | | Product Hunt | A usable new product or significant update for makers, early adopters and other people interested in technology | Free to use | Use a personal account; direct upvote requests are prohibited; submission does not guarantee homepage featuring | [How Product Hunt works](https://www.producthunt.com/launch/how-product-hunt-works), [posting guide](https://help.producthunt.com/en/articles/479557-how-to-post-a-product), [Launch Guide](https://www.producthunt.com/launch) and [featuring guidelines](https://help.producthunt.com/en/articles/9883485-product-hunt-featuring-guidelines), checked 17 Oct 2026 | | DevHunt | A tool whose intended users are developers | Free permanent listing with a nofollow link; $19 launch; $49 boosted launch | Non-developer products are rejected; a maker submits product details and selects a launch week | [DevHunt FAQ](https://devhunt.org/faq), checked 17 Oct 2026 | | BetaList | An unreleased, private-beta or recently released technology startup | The cited criteria page does not state a submission price | The startup needs a distinct page and a way for visitors to sign up, download or get access | [BetaList criteria](https://betalist.com/criteria), checked 17 Oct 2026 | The table compares published mechanics, not likely results. None of these rules establishes how many visitors, users or customers a qualifying submission will receive. ### Show HN Use Show HN when people can try a substantive product you worked on personally and you can stay around to discuss it. The official page says early-stage work can qualify, but it excludes landing pages, sign-up pages and projects that users cannot try. It also tells makers not to ask friends to upvote or comment ([Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026). Skip Show HN when the only public asset is a waitlist, when the submission would be mainly a blog post, when the project is a quickly generated one-off, or when you cannot discuss your own work. Those exclusions and requirements come directly from the same [Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026. ### Product Hunt Use Product Hunt when the product is usable and its intended users overlap with the platform’s stated community of early adopters, makers, tech people, entrepreneurs and people who enjoy trying new products. Product Hunt says it is free to use, recommends that makers post their own products and requires a personal rather than company account for posting ([how Product Hunt works](https://www.producthunt.com/launch/how-product-hunt-works) and [posting guide](https://help.producthunt.com/en/articles/479557-how-to-post-a-product), checked 17 Oct 2026). Skip Product Hunt when the product is only a waitlist without immediate access, when you have not prepared the product URL and submission assets, or when its technology-focused community is unrelated to the intended user. Product Hunt says waitlisted products without immediate access are not featured, and its posting guide asks for a product URL, name, tagline, topics, thumbnail, pricing status, gallery, description, makers and first comment ([featuring guidelines](https://help.producthunt.com/en/articles/9883485-product-hunt-featuring-guidelines) and [posting guide](https://help.producthunt.com/en/articles/479557-how-to-post-a-product), checked 17 Oct 2026). ### DevHunt Use DevHunt when developers are the intended users and the product fits its published categories, which include open-source projects, APIs, SDKs, frameworks, libraries, command-line tools, testing, monitoring, DevOps, databases, authentication products, agents and MCP servers. A permanent tool listing is free with a nofollow link; the published launch options are $19 and $49 ([DevHunt FAQ](https://devhunt.org/faq), checked 17 Oct 2026). Skip DevHunt when the user is not a developer. DevHunt explicitly says [non-developer products are not accepted](https://zeroraised.com/launch-sites/devhunt). Also skip the paid launch while you still need a private product test. Paying for a launch does not replace product access, positioning or the ability to support users. The acceptance rule and prices are sourced from [DevHunt](https://devhunt.org/faq), checked 17 Oct 2026; the recommendation to wait is ZeroRaised editorial advice. If the product is open source, use the [open-source project marketing guide](https://zeroraised.com/blog/how-to-market-an-open-source-project) to connect repository readiness, distribution and community support. ### BetaList Use BetaList when the product is a technology startup that is unreleased, in private beta or recently released. Its criteria require a distinct product page and a way for visitors to sign up, download or get access. BetaList also says each startup has two feature opportunities, one before release and one during release, with at least a few weeks between them ([BetaList criteria](https://betalist.com/criteria), checked 17 Oct 2026). Skip BetaList when the product is a blog, newsletter, online course, online store, consultancy or agency, because those categories are excluded by its criteria. Also skip it if the only page is on a free hosting subdomain or has too little product information, both of which the criteria list as unsuitable ([BetaList criteria](https://betalist.com/criteria), checked 17 Oct 2026). For a broader platform list, use the [Product Hunt alternatives guide](https://zeroraised.com/blog/product-hunt-alternatives-for-bootstrapped-makers). For a stage-first decision, use [where to launch a SaaS](https://zeroraised.com/blog/where-to-launch-a-saas). Do not turn this no-audience plan into a directory-submission marathon. ## How do you write the launch post? Write a fresh post for the venue. The shared facts can stay the same, but the title, opening and requested response should fit the context. This section is editorial advice except for the cited platform rules. Use five parts: 1. **What it is:** one sentence naming the user, job and result. 2. **Why you built it:** the specific observation or problem that led to the product. 3. **What works now:** the smallest honest description of the current release. 4. **What remains limited:** access conditions, incomplete areas and important constraints. 5. **What response you want:** one question a reader can answer after trying the product. For Show HN, write the post yourself. Hacker News says not to put generated text in submissions and not to post generated or AI-edited text in comments. Its Show HN page also asks makers to explain how and why they built the project ([Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html) and [Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026). A practical Show HN title is descriptive rather than promotional: > Show HN: [Product], a [concrete product type] for [specific job] Do not add praise, urgency or a gratuitous number. Hacker News asks submitters not to use uppercase, exclamation points or claims about how great a submission is, and it asks them to remove gratuitous numbers from titles ([Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html), checked 17 Oct 2026). For Product Hunt, prepare the specific fields the official posting guide requests. These include the direct product URL, product name, short tagline, a few relevant topics, thumbnail, pricing status, gallery, description, maker accounts and first comment. The guide recommends a 240 by 240 thumbnail and 1270 by 760 gallery images, while requiring at least two gallery images before the gallery is viewable ([Product Hunt posting guide](https://help.producthunt.com/en/articles/479557-how-to-post-a-product), checked 17 Oct 2026). Do not reuse the same call to action everywhere. Ask Show HN readers about a technical choice or their experience using the product. Ask a trade community about the workflow it exists to discuss. Ask Product Hunt visitors to try the product and comment, without asking directly for an upvote. Product Hunt explicitly permits sharing a launch link but prohibits direct upvote requests ([Product Hunt Launch Guide](https://www.producthunt.com/launch), checked 17 Oct 2026). ## What should happen in the two weeks before launch? This two-week schedule is ZeroRaised editorial advice. It is a workload plan for a solo maker, not a platform rule or evidence that fourteen days produces better results. ### Days 14 to 12: define the test Choose the core action, intended user and one launch objective. Write the first version of the positioning sentence. Create the ten-person list and remove anyone who does not have the problem. ### Days 11 to 9: test the full path Run the product from a fresh browser. Test the empty state, access flow, core action, support route and source tracking. Add sample data or a short demonstration if the first result needs context. Record every failure in one issue list. ### Days 8 to 7: recruit the first testers Send a personal request to a few intended users. Give each person one action to attempt. Observe without coaching when possible, then ask what they expected at the point where they paused. ### Days 6 to 5: fix the largest obstacle Group the observations into message, access, onboarding, product and support problems. Fix the obstacle that prevented the most important action. Do not spend the entire period polishing a screenshot while the core path fails. ### Day 4: select the venue Read the venue’s current rules from its own site. Reject a venue if the product type, access state or intended user does not fit. Prepare one primary venue only. ### Day 3: write the venue-specific post Draft the title, opening, build story, limitations and one requested response. Prepare the images and product details the venue asks for. Check every claim against the current product. ### Day 2: rehearse support Ask one tester to follow the actual launch link. Verify source tracking and the core action. Draft short answers to predictable questions about access, pricing, data handling and limitations, but answer the real question when it arrives rather than pasting a script. ### Day 1: stop adding scope Fix release-blocking faults only. Confirm that the product URL, support route and launch assets work. Clear time for replies and product support. If the core action is broken, postpone the post. That decision protects the user’s time. ## Should you launch everywhere at once? Usually no when one person is writing replies, providing support and fixing the product. This is ZeroRaised editorial advice, not a restriction imposed by the four venues. Launching in one place first gives you a cleaner source comparison and a manageable discussion. It also lets you correct a broken message or onboarding path before introducing another group. Separate launches by the work required, not by an arbitrary universal interval. Move on when you have answered active questions, handled urgent failures, recorded the result and made the next venue’s post genuinely appropriate to its audience. Use a second venue only when at least one condition changes: - The audience is different and the product fits its rules. - The angle is different, such as technical implementation rather than a general product introduction. - The product has changed enough to give the next group a better first-use path. - The release stage has changed, such as moving from a private beta to public access. Do not post the same paragraph into several communities. Read the current rules and write for the conversation already happening there. If a community prohibits promotion, do not disguise the launch as a request for feedback. ## What should you do on launch day? This operating checklist is editorial advice, with platform restrictions cited where relevant. 1. Open the public product path from a fresh browser before publishing. 2. Use the source-specific link prepared for that venue. 3. Publish the post and verify that its product link works. 4. Remain available for product support and questions. 5. Record repeated confusion in the issue list instead of debating the user. 6. Fix a blocking fault, then tell affected users what changed. 7. Save substantive questions for the follow-up plan. 8. Do not ask for prohibited votes or comments. Show HN forbids asking friends to vote or comment, and Product Hunt prohibits direct upvote requests ([Show HN](https://news.ycombinator.com/showhn.html) and [Product Hunt](https://www.producthunt.com/launch), checked 17 Oct 2026). Reply with useful detail. If someone asks why the product uses a particular approach, explain the constraint and tradeoff. If someone reports a failure, confirm what you can reproduce and what you will do next. If a question reveals that the positioning sentence is unclear, revise the page after the discussion rather than insisting that the reader misunderstood it. Do not judge the release from its rank. A platform may display votes, comments or selection status, but those are venue mechanics. Your launch objective should decide what counts as useful: completed core actions, conversations, purchases or another action chosen before publishing. ## How do you measure visits, activations and conversations by source? Measure a short path: source, visit, activation and conversation. In this guide, an **activation** is the first completion of the product’s core action with the user’s own data or real task. That is a ZeroRaised working definition, not a platform standard. Use one tagged link or distinct short path per venue. Keep the naming readable, such as `show-hn`, `product-hunt`, `devhunt`, `betalist`, `community-name` and `direct-outreach`. Do not put personal information in the link. If your current analytics tool cannot connect a visit to an activation, record a small aggregate count for each step instead of installing a complicated stack during launch week. | Measure | What to record by source | What it answers | Do not substitute | |---|---|---|---| | Visits | Sessions or unique visits to the launch page | Did anyone arrive from this source? | Platform impressions that never reached the product | | Activations | People who completed the predefined core action | Did visitors reach the first useful result? | Accounts created without product use | | Conversations | Replies, support exchanges or calls with an intended user that produced specific information | Did the source create a useful exchange? | Generic reactions with no product context | | Purchases or qualified next steps | Paid orders, requested proposals, booked evaluations or another preselected business action | Did the source contribute to the commercial objective? | Votes treated as revenue intent | | Repeated obstacles | The number of users who encountered the same message, access, onboarding or product problem | What should be fixed next? | A list of unrelated feature requests | The measures and definitions in this table are ZeroRaised editorial advice, not benchmark data. Compare sources on the same core action and access conditions. Do not declare one source superior because it produced more visits while another produced fewer but more relevant conversations. Keep a compact launch log with the date, venue, post URL, tagged product URL, visits, activations, conversations, purchases or next steps, repeated obstacles and changes made. Add qualitative notes only when they affect a decision. The log should help you decide what to fix and where to spend the next block of effort. The [first 100 users guide](https://zeroraised.com/blog/how-to-get-your-first-100-users) continues from this measurement step. It turns the first ten users, launch responses and useful channels into a staged path rather than assuming the public post completes distribution. ## How should you use the next 30 days? The following 30-day schedule is editorial advice. It is a follow-up discipline, not a claim that every product should improve on this timetable. ### Days 1 to 3: stabilize Handle access and product failures that block the core action. Answer outstanding questions. Separate defects from feature requests, and tell affected users when a fix is available. Do not begin another public launch while the first group cannot complete the promised task. ### Days 4 to 7: interview the evidence Contact people who attempted the core action. Ask one question tied to observed behavior: what they expected at a specific step, why they stopped or what they used instead. Do not ask “Would you use this?” when you can ask about what they already tried. ### Days 8 to 14: fix one repeated problem Choose the obstacle that most directly prevented activation or the launch objective. Change the message, access flow, onboarding or product. Ask the affected users to retry only if they agreed to follow-up contact. Record the change in the launch log. ### Days 15 to 21: compare sources Review visits, activations and conversations for direct outreach and the public venue. Compare the same action. Keep the conclusion narrow: “Source A produced three completed imports from these access conditions” is more useful than “Source A works.” The number is an example of sentence structure, not observed ZeroRaised data or a benchmark. ### Days 22 to 26: publish the useful lesson Turn a recurring question into documentation, an onboarding note, a demonstration or a technical explanation. Do not manufacture a success story. Publish only what you can show and explain. If the lesson fits a community, check its current rules before sharing it. ### Days 27 to 30: choose the next experiment Repeat the source that produced the intended action, adapt the post for a second suitable venue, or return to direct user recruitment. Choose one. If no source produced useful actions, revisit the intended user, problem and first-use path before expanding promotion. ## What are the most common mistakes when launching with no audience? ### Treating a waitlist as a tryable product A waitlist can be appropriate for BetaList, whose criteria include unreleased startups and require a way to sign up or get access. It is not appropriate for Show HN, which excludes sign-up and landing pages ([BetaList criteria](https://betalist.com/criteria) and [Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026). ### Choosing the site before the user Venue popularity does not repair an undefined audience. Write the user, problem, core action and launch objective first. This is editorial advice. Then eliminate any venue whose rules or community do not fit. ### Buying promotion before observing use Paid visibility cannot tell you why a suitable user failed to reach the core action. With the no-budget constraint in this guide, use direct tests and free routes first. Product Hunt is free to use, while DevHunt offers a free listing but charges for its launch options ([Product Hunt](https://www.producthunt.com/launch/how-product-hunt-works) and [DevHunt](https://devhunt.org/faq), checked 17 Oct 2026). ### Asking for votes Do not ask people to manufacture engagement. Show HN says not to ask friends to vote or comment. Product Hunt allows makers to share their launch link but says they cannot ask directly for an upvote ([Show HN](https://news.ycombinator.com/showhn.html) and [Product Hunt](https://www.producthunt.com/launch), checked 17 Oct 2026). ### Using generated copy on Hacker News Hacker News says not to put generated text in posts and not to post generated or AI-edited comments. Write the Show HN submission and responses yourself ([Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html), checked 17 Oct 2026). ### Launching everywhere at once Several simultaneous discussions can exceed one maker’s ability to reply, support users and attribute results. That is an editorial operating judgment, not a platform restriction. Start with one venue and move on after you have recorded and acted on the result. ### Measuring accounts instead of use An account is not evidence that the user completed the useful task. Define activation before launch, then record it by source. This is the measurement standard used in this guide, not an external benchmark. ### Changing several things at once If you rewrite the promise, onboarding and core feature together, the next result will not tell you which change mattered. Prefer one clear change tied to an observed obstacle. That is experimental discipline suggested by ZeroRaised, not a guarantee of causation. ## Where ZeroRaised fits ZeroRaised is included because it publishes this article. Makers can review the current board on the [home page](https://zeroraised.com/), read the current eligibility policy on [About](https://zeroraised.com/about#funding-policy), and use the [submission page](https://zeroraised.com/submit) when the product fits. The submission page states that submitting is free ([ZeroRaised submission](https://zeroraised.com/submit), checked 17 Oct 2026). Treat ZeroRaised like every other venue in this guide: read the current requirements, prepare an accurate product page and make no traffic or outcome assumption. If operating costs are the immediate constraint, the [perks page](https://zeroraised.com/perks) links to current vendor terms for tools, discounts, credits and free tiers, and the [free ramen profitability calculator](https://zeroraised.com/tools/ramen-profitability-calculator) turns your monthly spend into the number of paying customers you would need to cover it. For product-specific preparation, use the [app store screenshot guide](https://zeroraised.com/blog/app-store-screenshots-for-launch), the [Chrome extension launch guide](https://zeroraised.com/blog/how-to-launch-a-chrome-extension), or the [vibe coded app launch guide](https://zeroraised.com/blog/how-to-launch-a-vibe-coded-app). AI products also have a dedicated [AI app launch guide](https://zeroraised.com/blog/how-to-launch-an-ai-app), and AI-assisted builds should pass the [vibe coded app security checklist](https://zeroraised.com/blog/vibe-coded-app-security-checklist). Before publishing, use the [business domain name guide](https://zeroraised.com/blog/how-to-choose-a-domain-name-for-your-business) for the public address and the [app store keyword research guide](https://zeroraised.com/blog/app-store-keyword-research-for-indie-apps) for mobile discovery. If MicroLaunch fits the venue sequence, follow the [MicroLaunch guide](https://zeroraised.com/blog/how-to-launch-on-microlaunch) for its queue and paid options. Use the [traffic spike guide](https://zeroraised.com/blog/how-to-handle-traffic-spikes) to decide what to protect, shed and inspect if launch visitors arrive faster than the product can serve them. If account sign-in is part of the release, use the [passkeys vs passwords guide](https://zeroraised.com/blog/passkeys-vs-passwords-for-saas) to choose the authentication rollout and recovery plan. After the launch foundation is ready, the [30-day plan for new SaaS growth](https://zeroraised.com/blog/first-step-new-saas-growth) connects the first release to user conversations, onboarding repairs and the next channel choice. For a founder-community release, use the [Indie Hackers launch guide](https://zeroraised.com/blog/how-to-launch-on-indie-hackers) to shape a useful post and follow its promotion rules. For positioning and distribution after an AI-assisted build, use the [vibe coded app marketing guide](https://zeroraised.com/blog/how-to-market-a-vibe-coded-app). If Claude infrastructure credits fit the product, use the [Anthropic startup credits guide](https://zeroraised.com/blog/anthropic-credits-for-startups) to check eligibility and plan for costs after the offer ends. After shipping an update, use the [release notes guide](https://zeroraised.com/blog/how-to-write-release-notes) to explain user impact, required actions and breaking changes. ## Sources - [Hacker News, Show HN guidelines](https://news.ycombinator.com/showhn.html), checked 17 Oct 2026 - [Hacker News guidelines](https://news.ycombinator.com/newsguidelines.html), checked 17 Oct 2026 - [Product Hunt Launch Guide](https://www.producthunt.com/launch), checked 17 Oct 2026 - [Product Hunt, How Product Hunt works](https://www.producthunt.com/launch/how-product-hunt-works), checked 17 Oct 2026 - [Product Hunt, How to post a product](https://help.producthunt.com/en/articles/479557-how-to-post-a-product), checked 17 Oct 2026 - [Product Hunt featuring guidelines](https://help.producthunt.com/en/articles/9883485-product-hunt-featuring-guidelines), checked 17 Oct 2026 - [DevHunt FAQ](https://devhunt.org/faq), checked 17 Oct 2026 - [BetaList criteria](https://betalist.com/criteria), checked 17 Oct 2026 - [BetaList support](https://betalist.com/support), checked 17 Oct 2026 - [ZeroRaised home board](https://zeroraised.com/), [submission page](https://zeroraised.com/submit), [perks](https://zeroraised.com/perks) and [eligibility policy](https://zeroraised.com/about#funding-policy), checked 17 Oct 2026 ## Frequently asked questions ### Can I launch a bootstrapped app with no audience and no budget? Yes. Make the product easy to try, recruit ten intended users directly, choose one suitable free venue and reserve money for essential product operations rather than promotion. This is ZeroRaised editorial advice, not a promise of traffic or customers. ### Can I submit a landing page to Show HN? No. Show HN lists sign-up pages and landing pages as off topic and asks makers to submit only when people can try the work. ### Can I ask people to upvote my launch? No on Product Hunt or Show HN. Product Hunt permits sharing a launch link but prohibits direct upvote requests, while Show HN says not to ask friends to vote or comment. ### Should I launch on several sites at once? Usually not when one person is handling replies and support. Separate the launches so you can answer questions, repair the product and attribute useful actions to each source. This is ZeroRaised editorial advice, not a platform rule. ### What should I measure after launch? Measure visits, completed core actions and useful conversations by source. Treat votes, impressions and account creation as diagnostics unless one of them is the result your product actually needs. This is ZeroRaised editorial advice, not benchmark data.