Why we built ZeroRaised for the launches that get overlooked

ZeroRaised was built to give bootstrapped indie makers a launch and discovery home where an existing audience or promotional budget is not treated as proof of product quality. It is for products with no institutional VC or accelerator equity. Its purpose is to show enough context for visitors to judge the work itself.

TL;DR

ZeroRaised exists because useful independent products can be difficult to assess on launch pages where attention, ranking and editorial selection are easily confused. The answer is not to promise every maker attention. It is to make eligibility explicit, ask for information that helps a visitor evaluate the product, keep paid placement separate from organic launches, and tell makers honestly what a launch board can and cannot do. The current submission route is free, asks for a public product page and does not require an account or payment.

On 17 Oct 2026, an Ask HN post questioned whether handmade games were still worth showing to the public internet. Its author described concern that individual work could be dismissed as AI output while mainstream material dominates attention. That single discussion does not establish a wider trend, but it captures the problem ZeroRaised was created to address: giving independent work a clear place where visitors can inspect what was made, who made it and whether it is worth their time.

Why we built ZeroRaised#

There is a particular kind of launch that rarely begins with a campaign team. The maker fixes the awkward edge, checks the screenshots, writes the announcement, answers support questions and watches the first unfamiliar visitors try the product. The work is real even when the surrounding audience is small.

We like those launches. ZeroRaised was built to give them a proper place to land.

The original idea was simple: a careful product should not need a large existing crowd, an investor network or a deep promotion budget before somebody can inspect it. That does not mean a new board can manufacture demand. It means the board can remove some avoidable ambiguity. A visitor should be able to see what the product does, who made it, whether it can be tried and what the maker learned by releasing it.

This focus is narrower than a general startup directory. The published eligibility policy accepts products supported through self-funding, customer revenue, friends and family, crowdfunding and non-dilutive grants, while excluding any product that has ever received institutional VC or accelerator equity. The rule applies to past as well as current funding, and submissions are reviewed before publication.

The word “bootstrapped” can otherwise carry too much hidden judgement. It can start arguments about whether consulting revenue counts, whether a grant counts, or whether help from family counts. ZeroRaised uses a concrete boundary instead. The boundary is about a product's funding history, not a purity contest about how hard somebody worked.

That distinction gives the visitor useful context without asking the maker to perform hardship. It also gives the site a clear editorial job: apply the published rule consistently, explain any sponsored treatment and avoid turning an opaque score into a verdict on the quality of the business.

The problem is not a shortage of launch sites#

Makers already have many places to announce work. The harder problem is that those places do different jobs while looking superficially similar. A product page, a ranked board, an editorial feature, a discussion thread and a software directory are not interchangeable.

Product Hunt describes itself as a community where people share, discover and discuss new products. Its homepage order uses upvotes, comments, time since submission and other undisclosed factors, while homepage featuring is a separate editorial decision. Product Hunt also says that appearing on the site does not guarantee featuring (Product Hunt overview, checked 18 Oct 2026 and featuring guidance, checked 18 Oct 2026).

Show HN has a different shape. It asks people to post something they personally made and that other people can try, then remain available for discussion. Sign-up pages, newsletters and material that cannot be tried are outside the Show HN format. Every qualifying submission begins in the new-submission stream, and the rules prohibit asking friends to vote or comment (Show HN guidelines, checked 18 Oct 2026).

BetaList explicitly covers products that are unreleased, invite-only or recently released. Its criteria require a technology startup, a distinct product page and a way for visitors to sign up, download or gain access. It also offers separate opportunities around the pre-release and release stages (BetaList criteria, checked 18 Oct 2026).

DevHunt narrows the audience by product type. It accepts developer tools such as open-source projects, application programming interfaces, software development kits, frameworks, libraries, editors, command-line tools, testing products and infrastructure tools. A listing receives a permanent page, while the scheduled launch programme and boosted treatment are paid options (DevHunt FAQ, checked 18 Oct 2026).

Those are not flaws. They are different mechanisms. Trouble begins when a maker reads every mechanism as the same promise: submit a product, receive fair attention, find customers. None of the cited platforms makes that blanket promise.

The table explains mechanics, not likely outcomes. A homepage, permanent page, discussion thread or followed link is a feature of a venue. It is not evidence that the right user will arrive, understand the product or become a customer.

That distinction matters especially for a solo maker. Time spent rallying contacts, adapting copy, answering comments and fixing onboarding is real operating work. Choosing a launch site is therefore not just a marketing choice. It is a choice about which rules, audience and feedback format are worth the maker's limited attention.

Momentum can hide the information a visitor needs#

Launch boards often need some way to order products. Public reactions can help, because they show that people found something interesting enough to respond. Editorial selection can help too, because somebody can remove spam and surface work that fits the audience. Paid placement can support a site when it is clearly marked. The problem is not that these mechanisms exist. The problem is that they can blur together.

A visitor may see a product near the top and reasonably wonder what put it there. Was it community interest, an existing audience, editorial judgement, recency, payment or a mixture? Product Hunt openly says its homepage order includes engagement, time and other factors, and it separately explains editorial featuring (Product Hunt overview, checked 18 Oct 2026 and featuring guidance, checked 18 Oct 2026). DevHunt openly distinguishes a free permanent listing from paid launch treatments (DevHunt FAQ, checked 18 Oct 2026). Clear rules let a maker decide whether the mechanism fits.

ZeroRaised's response is to make the categories legible. The editorial policy says sponsored placements are labelled, have no vote button or rank, and do not replace a launch in the organic list. It also says rankings, upvotes and organic positions are not for sale. That is more useful than pretending money never exists around discovery. The visitor gets to know what they are looking at.

The same policy avoids claims about traffic, conversions or launch results. That restraint is deliberate. A board can provide a page, a review process and a context for discovery. It cannot know whether a particular maker's positioning, onboarding, price or product will turn a visit into lasting use.

This is why “fair” cannot mean “every product receives the same outcome”. Products differ, audiences differ and visitors make their own choices. A fairer board can instead mean visible eligibility, consistent review, labelled commercial treatment and no sale of an organic position. Those are promises the publisher can actually control.

The product page should do more than carry a logo#

A logo, a short tagline and a button are not enough to evaluate unfamiliar software. They may look tidy, but they place nearly all the work on the visitor. The visitor still has to discover the user, the problem, the current state of the product and the reason to trust the page.

ZeroRaised therefore starts from four practical questions:

• What does the product do?
• Who made it?
• Can somebody try or inspect it now?
• What did the maker learn by shipping it?

These questions came from the original ZeroRaised story. They are not a claim that every product will have the same card or that the interface will never change. They are an editorial test for whether the page gives a curious person something more useful than a slogan.

The live submission form currently begins with a public product URL. It says ZeroRaised fetches the product name, icon and tagline, then asks the submitter to confirm the remaining information. It also states that submission is free and requires neither an account nor payment. Those details reduce submission friction, but they do not remove the maker's responsibility to maintain a clear public page.

“Public” is important. A visitor should not have to join a private group merely to learn the basic proposition. A product can still require an account for its real service, but its public page should explain who it serves, what happens after the click and any access condition that changes the visitor's decision. This paragraph is ZeroRaised editorial advice rather than a platform rule.

The same principle applies to the maker story. Useful context is not a long autobiography. It is the reason the problem mattered, the constraint that shaped the solution, the trade-off the maker chose and the lesson another builder can test. A concise, specific note is more helpful than a heroic origin story with no connection to the product.

For makers preparing that material, the bootstrapped product launch checklist covers positioning, product-path testing and launch operations. The guide to getting initial users explains why launch traffic should feed a repeatable learning process rather than stand alone as a one-off spike.

Funding context is useful when the rule is precise#

ZeroRaised is not meant to decide whether a company is morally good. Its funding boundary defines the collection. The policy allows self-funding, customer revenue, friends-and-family support, crowdfunding and non-dilutive grants. It excludes a product that has ever taken institutional VC or accelerator equity.

That makes the board more coherent for two groups. A maker knows whether the product belongs before investing time in a submission. A visitor knows that the products share a material constraint, even though their industries, prices and stages may differ.

The boundary also protects the word “indie” from becoming merely decorative. Without a published rule, a site could apply the label to almost any startup. With a rule, a reader can disagree with the boundary but still understand it. Clear disagreement is healthier than vague inclusion.

There are many legitimate ways to build outside institutional equity. Customer revenue, savings, service income, crowdfunding and non-dilutive support create different pressures and different degrees of control. The guide to funding a product without venture capital examines those routes without claiming that one route fits every maker.

Eligibility still needs evidence. The about page says funding evidence and editorial details are reviewed before a page can become eligible for search indexing. Review cannot turn a public policy into perfect knowledge, but stating the review step is better than asking visitors to assume that every label verifies itself.

Small software on purpose#

The original post also made a technical promise about character: keep the site understandable, repairable and inexpensive to operate. That is not an architectural specification. It is a preference for the smallest system that can support the editorial promise.

const launchRule = {
  institutionalEquity: false,
  status: "shipped",
  pitchDeckRequired: false,
};

That object is not the production schema. It is the editorial idea in miniature. Zero is not a consolation prize here. It is the shared funding constraint that makes the collection coherent.

Small software does not mean careless software. A narrow product still needs reliable submission handling, review, abuse controls, clear states and pages that work for unfamiliar visitors. It means resisting a maze of services or decorative features when a direct implementation can do the job.

This preference also shapes what does not belong on the page. More badges do not automatically make a product easier to evaluate. A proprietary score does not become objective because it has decimal places. Activity counters can create urgency without explaining relevance. Every element should earn its place by helping a maker submit, helping a visitor decide or helping the publisher apply the policy.

That restraint leaves room to change the mechanics. A growing board may need better review tools, clearer categories or different ways to archive launches. Changing those mechanics is compatible with the original promise as long as sponsored placement stays labelled and organic placement remains outside the sales catalogue.

Discovery should continue after the launch moment#

One release post rarely solves distribution. Product Hunt calls itself a place to share and discuss new products, Show HN centres a discussion around work people can try, and BetaList serves particular release stages (Product Hunt overview, checked 18 Oct 2026, Show HN guidelines, checked 18 Oct 2026 and BetaList criteria, checked 18 Oct 2026). Each can be useful without becoming the whole marketing plan.

For ZeroRaised, discovery also includes practical resources around the board. The maker perks page links to vendors' own terms for public offers, states that public offers are not sponsorships and says the publisher does not take a cut from them. Its sponsor section separately describes how a partner can provide a maker offer and receive labelled placement, without a promise of clicks or sign-ups.

That separation matters because a perk, a sponsor slot and an organic launch serve different purposes. A perk can reduce the cost of building. A sponsor slot is commercial distribution. An organic launch is a submitted product assessed under the site's policy. Putting all three behind one vague badge would make the board harder to trust.

Makers still need channels they control. A useful launch can reveal which wording brings the right people, which onboarding step fails and which questions repeat. The next move is to turn that evidence into a better product page, clearer documentation, an email list with consent, search content that answers a real question or direct outreach to a well-defined user. The free marketing channels guide separates launch boards, communities, directories and owned channels so the release is not mistaken for a complete acquisition system.

The right sequence depends on the product. A developer tool may fit Show HN or DevHunt because developers can inspect it and discuss the build. An unreleased technology product may fit BetaList if visitors can register or obtain access. A usable product aimed at tech enthusiasts may fit Product Hunt. A bootstrapped product that meets the published funding boundary may fit ZeroRaised. These fit statements follow the current platform rules, not forecasts of results (Show HN guidelines, checked 18 Oct 2026, DevHunt FAQ, checked 18 Oct 2026, BetaList criteria, checked 18 Oct 2026, Product Hunt overview, checked 18 Oct 2026 and ZeroRaised policy).

What makers can reasonably expect#

A maker can reasonably expect the published rules to mean something. On ZeroRaised, that means a reviewed funding boundary, labelled sponsorship, organic positions that cannot be bought and editorial guides that cite primary sources (ZeroRaised policy). The maker should not infer an audience size, a conversion rate or a sales result from those promises.

A maker should also expect to bring a product that can survive the click. The submission page asks for a public product URL (ZeroRaised submission). Before submitting, open that page in a fresh browser, follow the main path, check the pricing or access explanation, read the copy without private context and make sure the support route works. This preparation is editorial advice.

Then write for the person who has never heard the backstory. Name the user, the job, the current product state and the reason the approach differs from an obvious alternative. Replace unsupported superlatives with evidence people can inspect. If the product is early, say what is incomplete. If access is limited, say how it works.

Finally, choose the question the launch should answer. Perhaps visitors misunderstand the category. Perhaps they understand the promise but stop during setup. Perhaps a specialist group asks for an integration the maker had not considered. A launch becomes useful when it produces a decision, not when the maker spends the evening refreshing a rank.

This is also why the board should preserve context after voting ends. A product page can remain a record of what was released, how it was described and what the maker learned. That record is useful even when the launch did not dominate a ranking.

What visitors should be able to trust#

Visitors deserve clarity about provenance. They should be able to distinguish a maker submission from an editor's selection and an organic position from sponsored placement. At the time of this update, the home board identifies products selected by ZeroRaised while it waits for submitted launches, rather than presenting those selections as maker submissions.

Visitors should also be able to follow the product link and form their own view. A launch board is an introduction, not a certification of security, reliability, value or long-term viability. Buyers still need to inspect the product, its terms, its privacy practices and any evidence relevant to their own risk.

The editorial guides follow a similar principle. The published standards require primary sources for platform claims, dated checking, no invented traffic or conversion figures, explicit silence when a public source does not answer a question, and disclosure when ZeroRaised appears in its own comparison. Those rules do not make every judgement infallible. They make the judgement easier to audit and correct.

Corrections are part of that promise. The same policy provides a correction route for changed costs, account rules and submission details. Launch platforms change their mechanics, so a useful guide must show its sources and acknowledge when the evidence moves.

What happens next#

The job now is to make the board useful one clear decision at a time: good product pages, honest voting, visible maker context, labelled sponsorship and a defined beginning and end for each board. The mechanics can improve without turning the site into a scoreboard whose meaning nobody can explain.

The blog will stay close to that work. Useful subjects include pricing decisions, launch post-mortems, small technical choices, distribution experiments and maker accounts that provide evidence rather than universal claims. The aim is not a stream of empty announcements. It is a reference shelf a maker can use before and after a release.

ZeroRaised cannot make an indifferent market care, and it should not pretend to. It can give eligible work a clear page, place it beside products built under the same funding constraint, separate commercial placement from organic treatment and publish the rules used to make those decisions.

If you have shipped an eligible product independently, submit it here. If you are still planning the release, start with the guide to launching a bootstrapped app, check the current member perks, read the funding and editorial policy, and use the launch checklist before sending the product. The pencil marks may remain visible. That is preferable to pretending the first version is final.