Launch Your Project

To launch a project here, get it live, write a one-line factual summary, then send it through the submit form with your GitHub username. An editor checks the link and the summary before it is listed. This page is the checklist for doing it well. Checked 31 October 2026.

What you need before you start

Choose "Something you built with an agent" on the form. Submissions of agents, add-ons and prompts use other options. Read how launches work first if you want the full picture.

Step 1: get it live and working

A launch with a broken link is the most common reason to decline. Check these on a phone as well as a laptop, signed out:

• The page loads over https without warnings.
• The first screen says what the project does.
• Sign-up and forms work.
• Nothing shows an error, a placeholder or a "coming soon" wall.
• It is not password protected.

If the project is on a builder's preview domain, say so in your notes. Custom domains need a paid plan on some builders. For Lovable the plan table lists custom domains as Pro and above. For Bolt, free sites carry Bolt branding and cannot use a custom domain.

Step 2: check the basics of safety

Projects built from a prompt often skip the dull parts. Before you ask people to try it:

1. No secrets in the frontend. API keys must not be in the code the browser downloads.
2. Authentication works as intended. Try opening a private page signed out.
3. Forms handle bad input. Try empty fields and very long text.
4. Data you collect has a purpose. Add a privacy note if you store anything personal.

The guides on securing a vibe-coded app and deploying a vibe-coded app go through these. If the project needs a professional fix, see vibe code rescue services.

Step 3: write the summary

The summary is the line we show on the card. It has to be a fact, not a pitch.

The examples above are illustrations of the wording, not real projects. The form accepts 20 to 200 characters. Say what it does, for whom, in plain words.

Step 4: submit

1. Open /submit/ and choose the launch option.
2. Fill in the name, live URL, summary and GitHub username.
3. Add the repository link if the source is public.
4. Send it.

If the form shows errors, it names each one. Typical ones: the link is not a full https:// address, the summary is too short or long, or the link is already in the directory or in the review queue.

Step 5: what happens next

Your submission becomes a draft credited to your GitHub account, marked "Not yet verified". An editor then:

1. Opens the live link and checks it matches your summary.
2. Looks for safety problems and misleading claims.
3. Adds our own short note.
4. Records the stack, using what you can tell us through contact.

The entry has to pass the gate in the methodology before it is public. We do not promise a date.

After it is listed

• Members can vote. Votes are one per signed-in member and feed the four leaderboards.
• Your link carries rel="ugc". That is normal for member links and not a penalty.
• You can ask to change the entry through contact.

Do not ask friends to create accounts only to vote. We have no promise about how we handle vote abuse beyond the one-vote-per-member rule.

What gets declined

Builder-specific pages

If you used a major app builder, the matching pages explain what qualifies and what we know about the tool: built with Lovable and built with Bolt. For something to build, see ideas.

Checklist

• Live, public, works on mobile
• No keys in the frontend
• Summary is one factual line
• GitHub username ready
• I know the agent, models and add-ons I used
• ] I read the [submission rules