Open-source AI project launch checklist

Most open-source AI launches fail quietly. The project is real, the code works, but a visitor arriving from a launch post spends ninety seconds looking for evidence, does not find it, and leaves. This checklist is about manufacturing that evidence before you ask anyone for their attention. It is written for AI projects specifically, because they carry extra baggage — model weights, API keys, GPU requirements — that generic launch advice ignores.

1. A README that answers three questions in one screen

Before scrolling, a first-time visitor should know: what this is, who it is for, and what it looks like. GitHub's README documentation describes the README as the place to explain why a project is useful and how people can get started. That means a one-sentence description that names the category ("a self-hosted web UI for local LLMs", not "reimagining how humans interact with intelligence"), a screenshot or GIF above the fold, and a quickstart visible without scrolling past a wall of badges.

Write the sentence before polishing anything else, because it becomes your launch tagline, your repo description and your social post. If you cannot write it, the project is not ready to launch — not because the code is bad, but because you have not yet decided who it is for.

2. A demo that works without a wallet

AI projects have a unique friction: many require an API key or a GPU before showing any value. Lower that wall as far as you can. A hosted demo with a rate limit beats everything. Failing that, record a two-minute video of a real session — unedited, showing actual latency, because developers trust imperfection. If your tool wraps local models, state the minimum viable hardware honestly ("runs on an 8GB M1, slowly") and consider bundling a small default model so the first-run experience is not a hunt through a model catalog.

Whatever the demo is, link it in the first screen of the README and test it from a machine that is not yours.

3. Licensing that survives a lawyer's glance

Two layers matter. Your code needs a license file: GitHub's repository licensing guidance explains that without a license, default copyright law applies. MIT and Apache-2.0 maximize adoption; AGPL is a legitimate choice that you should make deliberately, knowing it filters out some corporate users. The second layer is AI-specific: if you distribute or download model weights, their licenses are not your license. Llama-family weights, for instance, carry use restrictions that an MIT badge on your repo does not erase. One paragraph titled "Model licensing" saves your users a compliance surprise and signals that you know the terrain.

4. An install path that survives a stranger

Your machine has accumulated state that no fresh environment shares. Test your install instructions in a clean container or VM, character by character. State prerequisites with versions ("Python 3.11+, Node 20+, Docker 24+"), provide a copy-paste block that ends with something visibly working, and list the three most likely failure modes with fixes — port already in use, missing API key, wrong CUDA version. For anything served over HTTP, ship a Compose file: the Docker Compose documentation defines it as a way to describe and run multi-container applications from a single YAML configuration.

5. Security notes, because AI tools touch secrets

An AI tool typically handles API keys, user prompts, and sometimes uploaded documents or tool execution. Say explicitly: where keys are stored and whether they ever leave the machine; what telemetry exists and how to disable it; and what a prompt injection could reach if your tool executes code or browses. OWASP's prompt-injection guidance is a useful minimum threat-model reference. Also explain how to report a vulnerability; GitHub documents a standard SECURITY.md policy workflow. Four honest sentences here build more trust than any badge, and their absence is increasingly disqualifying for team adoption.

6. A maker story people can retell

Launch posts that read like press releases die; launch posts that read like engineering diaries travel. Write down the specific moment the problem annoyed you enough to build, what you tried that failed, and the one design decision you are most unsure about. That last part matters: admitting uncertainty invites the exact feedback a launch is for. Keep it under three hundred words and put it in the launch post, not the README.

7. Launch mechanics: sequence, don't blast

Treat channels as tiers. Tier one is where your users actually are — for developer AI tools, that is Hacker News, relevant subreddits like r/LocalLLaMA or r/selfhosted, and AI directories such as AIPO.ST, where a launch takes ten seconds and gives you a product page plus an embeddable badge. Before posting, read the official Show HN guidelines: the project should be something people can try, and the post should make it easy to understand and access. Tier two is social amplification — X and LinkedIn threads summarizing the story with the demo link. Sequence them: directory and community posts first to concentrate early activity, social the same afternoon pointing at wherever discussion is liveliest.

On launch day, your only job is presence. Answer every comment within the hour, including the hostile ones — especially the hostile ones, because bystanders judge you by those replies. Have a pinned "known issues" thread ready so the same bug report does not fragment across five platforms.

Timing: launch on a Tuesday, freeze on a Friday

Two scheduling rules earn their keep. First, freeze the repository the Friday before: no refactors, no dependency bumps, nothing that could break the quickstart while you sleep. Launch weeks punish cleverness — the commit you push at midnight before launch day is statistically the one that breaks the demo. Second, launch early on a weekday morning in your primary audience's timezone — Tuesday through Thursday, US morning hours for Hacker News — so the post accumulates activity while the maximum number of your users are awake. Weekend launches feel calmer but bury you: less traffic and, worse, fewer people around to answer the first wave of questions. Set aside the entire launch day. It is not a day for writing code.

8. The week after: convert attention into a project

Attention decays in seventy-two hours; converting it is the actual goal. Triage every issue within a day, even with just a label and a "confirmed, looking into it". Turn the three most-asked questions into README sections. Tag a release with the launch-week fixes so early adopters see motion. Then publish a short "what I learned launching" follow-up — it consistently earns a second, smaller wave of attention and closes the loop with everyone who commented.

Finally, write down your numbers — stars, uniques, installs, sign-ups — not because they are large, but because your second launch (the 1.0, the big feature) will need a baseline. Launches are repeatable events, not one-shot verdicts, and the projects that win usually launched four times.