Show HN launch checklist for moonlighting micro SaaS

For moonlighters, Show HN is decided the day before

If you treat Show HN as a decision you make in the moment of clicking the submit button, it becomes the worst possible channel for a moonlighting engineer. What survives on the front page is decided by what you can return in the few hours after submission, and if those hours overlap with day-job meetings, it's over. So when you ship on the side, the only sane play is to push 90% of the Show HN work to before the submit button.

I run gpdf and gsql as Pure Go OSS (MIT) outside my day job as a contract tech lead — the operational shape is in the nadai ecosystem post. What follows is the checklist I'm assembling to get gpdf ready for Show HN, written so I can reuse it for the next launches (gpdf-api and the gsql announcement). The post hasn't gone up yet, so read this as "items that lower the chance of missing," not as "do this and you'll reach."

Five assets to lock in the day before

The hard constraint when you moonlight is that real-time bandwidth on launch day is essentially zero. So I prepare five pre-written assets the day before. On the day, I want to be pasting, not composing.

• Title: Stick to Show HN: <product> – <one concrete benefit>. Under 70 characters, benefit instead of feature. Something like Show HN: gpdf – Pure Go zero-dependency PDF generator with CJK support, where what it does and what's different both fit on one line.
• What's visible in the first 30 seconds: The README intro or the LP hero. One animated GIF, one code snippet, or one screenshot that proves "this works" instantly. The moment you start explaining in prose, reach gets cut in half.
• Comparison table: Differences from existing tools in a single table. For me, that meant comparing against gofpdf, go-pdf/fpdf, UniPDF, gopdf, and Maroto, with axes like "Pure Go / no CGO / actively maintained / license / CJK font support." Tables are the structure technical communities read fastest, and they get quoted in HN comments.
• A FAQ for replies: Read ten past Show HN threads and the top-comment patterns collapse into roughly five or six: "What's the license?" "How does this differ from ?" "Any benchmarks?" "Is commercial use okay?" "Why didn't you just fork X?" Pre-write 3–4 line answers and have them ready to paste on the day.
• Your first comment, drafted: The author's first comment on the thread visibly affects reach. In 5–7 lines, write honestly about why you built this, what existing tools were missing, and what isn't supported yet. Stating what's not supported tends to raise initial trust, in my experience.

The one I underweighted prepping gpdf was the comparison table. I'd buried competitor mentions in README prose, and the moment I pulled them out into a table the page got noticeably easier to read. Choosing prose vs. choosing a table is a different call from "is the content correct" — I learned that one the hard way. The fix was mechanical: extract every paragraph that compared gpdf to another library, distill the row to four to five axes, and delete the prose.

A side observation: the FAQ stash also doubles as your README polish list. Anything that ends up in the FAQ probably should have been answered in the README in the first place. I grafted three FAQ answers back into the README during prep, which turned out to be the cheapest documentation pass I've done.

On the day: posting time and the first 90 minutes

The widely-quoted sweet spot is US East Coast weekday mornings, 8:00–10:00 (21:00–23:00 JST). I'm aiming at this band too. The HN front-page residency tends to be decided by the traffic that starts in this window.

Time isn't decisive though. At the same hour, the day's competing posts will swing your initial trajectory. My intuition is the breakdown is roughly: time 10%, title 30%, what's visible in the first 30 seconds 30%, opening comment 30%. Stacking the five assets above pays better than fussing over the clock.

The first 90 minutes I run like this:

1. 0–5 min: Post your own first comment. Going first sets the anchor for the comment tree below it.
2. 5–30 min: Top comments start landing. Paste FAQ replies for matching patterns; hand-write replies for new ones.
3. 30–90 min: This is when you can see whether you're holding the front page. If you are, GitHub issues and discussions start coming in too — narrow your notification surface to one channel and watch it.

If those 90 minutes collide with a day-job meeting, you're cooked. I'm picking a launch day that falls on a weekday with no evening meetings on my calendar. Moving the day-job schedule costs less than late-replying on Show HN day — late replies in a Show HN thread read as either "the author isn't engaged" or "the author can't keep up with criticism," and both kill momentum.

A practical add: pre-tether your phone to the same network you'll be on, sign into HN on mobile in advance, and verify you can paste from your FAQ doc to the HN reply box without a desktop. The number of small environmental papercuts you can hit in the first thirty minutes is non-trivial, and you don't want to discover them at minute three.

Handing the launch to adjacent communities

Don't let Show HN be the whole launch. As a hedge against not landing on HN, line up adjacent communities ahead of time. My options:

Community	Format	Timing
Hacker News (Show HN)	Primary link post	US East Coast morning, weekday
Lobsters	Link post	Same day as HN, 2–3 hours offset
reddit r/golang	Self-post with context	A different day (reddit weekends are busier)
Go Weekly / Awesome Go	PR or submission form	During the release week
Twitter/X	Personal account intro	Right after posting

Hitting all of them simultaneously reads as marketing and tends to play badly. I keep HN primary, Lobsters same-day with an offset, and reddit on a separate day.

The deeper point is not "if Show HN flops, fall back to others." It's that Show HN is one channel among several from the start. Even if you don't hold the front page, picking up 50 stars from Lobsters and r/golang lands you in roughly the same place. Carrying channels as a portfolio is also better for the moonlighter's psyche, in my experience.

Common questions

"What about what happens after you hit 100 stars on Show HN?"

Out of scope here. This post is just about pre-launch prep. The continuous-operations and actual-numbers post is planned for after four months of observation.

"Can I put pricing or discounts in the title?"

Show HN guidelines don't explicitly forbid pricing, but the community sniffs it out and reacts badly. I keep titles to a single feature benefit. The commercial framing belongs on the LP, not in the HN title.

"Can I keep mentioning my product name across replies?"

Also disliked. Naming your product when answering FAQs about it is fine; piggybacking on someone else's question with "you should try " is counter-productive. Stick to direct answers.

"Isn't Show HN past its prime?"

Alternatives exist (Product Hunt, dedicated Discords) but HN's position as the first-pass review community for technical products hasn't actually shifted, in my read. At least in Go OSS / developer-tooling, holding the HN front page is hard to replace.

Next steps

This is the Show HN prep list as of May 2026. I'll use it for gpdf and the next launches (gpdf-api, the gsql announcement) and append whatever it missed.

• Validation upstream of this: Pre-release validation for moonlighting micro SaaS
• Operational shape: nadai ecosystem: running multiple micro SaaS as one person
• Time design: Time design for a day-job tech lead also building OSS