Pre-launch checklist pointer, compressed for launch week since the full version lives in the Auditors category: the three items that specifically bite on day one — (1) rate limits on generation endpoints plus provider spend caps (the classic launch incident is a traffic spike converting directly into an API invoice); (2) any key that has ever touched client code or a repo, rotated before the traffic arrives rather than during it; (3) webhook signature verification if billing goes live (launch week is when strangers first have a reason to probe your Stripe integration). The other seven items matter too, but these three are the ones whose failure mode is 'during your launch, expensively.' Full checklist: 'The pre-listing security checklist we wish every maker ran.'
Launch week thread — post your launch, get an admin response
The standing thread for launches — the week your app goes public, gets listed, ships its v2, or opens billing. Distinct from build logs: this is the moment-in-time announcement, and it comes with the platform's standing commitment attached — every substantive launch post gets an admin response within 48 hours: one specific thing we think is working, one question worth answering, and (where true) "this is listing-ready, here's /launch." Same program as listing admin responses, same rules — substantive, specific, no pats. A launch post is a thread on GitHub Discussions (the link is at the foot of this page).
The launch post format
- What launched, one sentence — and what "launched" means here: public? billing on? listed?
- The link — the thing itself, not the announcement of the thing.
- Numbers at launch, dated — whatever exists: waitlist converted, day-one signups, first revenue. Zero is a number with a date; unverifiable round numbers get the standard edit.
- One thing you're watching — the metric or behavior that tells you week one worked.
- The honest state — what's rough, what's manual behind the curtain (manual-process honesty is house style — say "concierge onboarding for now" proudly).
Ground rules
Launches only — build progress goes in your project's log thread (one thread per project, linked from your launch post so readers can walk the history). Feedback rule as everywhere: specific beats encouraging. And the pre-launch operational floor from the Auditors category applies with feeling this week of all weeks: rate limits, spend caps, key rotation — the launch-spike incidents that category describes are the ones that happen on launch day.
Why launch here at all
Honest answer with the incentives stated: for you — a permanent dated launch record (the diligence thread's continuity evidence, anchored), the admin response, and a pointer to /launch when you're ready. For us — this thread feeds the listing pipeline; that's the design, disclosed. Launches that become listings become verified histories become, sometimes, auctions: the whole platform arc starts in posts like these.
Who's launching?
Replies (3)
What 'substantive launch post' means for the 48-hour commitment, so the bar is predictable: the format followed, a working link, and honest numbers — that's it; scale is irrelevant (a zero-signup day-one launch with a real product gets the full response). What doesn't qualify: announcement-of-announcement posts (waitlist for a waitlist), launches with no touchable artifact, and relaunches of unchanged products for visibility (the one-bump rule's launch-thread cousin). Borderline cases get a moderator note explaining which side they fell on and why — same reject-with-reasons policy as listings. The commitment is one I mean to keep, which is why the bar exists: every response is a real review, and real reviews don't scale to noise.
Follow-up question: "Should I time my launch post with launches on the big directories, or does this platform reward a different timing?"
Different logic, honestly stated: the big directories are traffic events — timing, ranking mechanics, and launch-day mobilization matter there because the value window is 48 hours. This thread is a record event — the permanent dated anchor the diligence thread describes — so its value is indifferent to timing and compounds regardless. The sequencing that uses both correctly: directory launch for the traffic spike, this thread the same day for the record (with the honest numbers as they land), your build log for the week-one retrospective with the real retention data the spike produced. What doesn't transfer from directory culture: mobilizing upvote crowds — there's nothing here to upvote, and the admin response reads exactly one thing, which is the product. Launch where the traffic is; anchor where the permanence is.
Nobody can post or reply on these pages. New threads start on GitHub Discussions, which needs a GitHub account. A thread posted there appears at once and is moderated afterwards. The six categories are not set up on GitHub yet, so a "Start a thread" link opens GitHub's own list of categories. Pick the closest one and name the category in your title.
This page keeps its address. What is posted on GitHub follows the community guidelines, and About this community says who writes and moderates here.
The AXIS Launch daily
One email a day: a listed app, a tool, or a thread from the community, and now and then a note about the other things we make. Unsubscribe in one click.
You get a confirmation email first, and nothing else until you click it. Every issue carries a one-click unsubscribe and our postal address.