My cofounder @kiet_onlook and I have now done two Hacker News launches, both of which had solid outcomes—the first even landed us on the front page and earned over 1,000 stars on our open source GitHub project.
Since we launched, a number of other founders have asked how to have a successful Hacker News post, so we decided to put this guide together. Hopefully this will help you maximize your chances of success, and will cover everything from the lead-up, to the post itself, and what to do afterward.
A lot of our advice leans towards launching an open source project, but there are useful lessons for every type of company.
The key to a great launch boils down to preparation. While it’s tempting to move fast, especially if you’re open sourcing a project, don’t skimp on the prep work. You want to position yourself for that initial surge of momentum because it will make all the difference in your results. Launch day is gameday, so make sure you’re ready to go!
Before the Launch: Prepping the Post
Your title is everything—it’s the only tool you have to catch attention, so it has to be curious and compelling. Spend the time to get this right because it’s really all you have to get people into the discussion. You should spend time sharing it with friends, testing it in tweets, and refining it to get people to ask for more information.
Think of this as the episode title you’d see on Netflix or Hulu – if it’s not interesting enough, people aren’t going to click.
Once you have your title, start crafting a strong post. Hacker News isn’t about blatant promotion—it’s about curiosity and sharing something meaningful. They say it in their rules, so be sure to read those first.
If you’re sharing a project, focus on the technical and interesting aspects, not a sales pitch, and be sure to be candid in your writing. It’s a very casual crowd.
There are two primary places to post:
We highly recommend Show HN, especially for a project launch, as it helps categorize your post in a space where people are specifically looking for new and exciting things. But remember—Show HN can’t just be pure promotion. Keep it light, keep it interesting.
Timing your post is another important consideration. From our experience, posting earlier in the week seems to have better results. We posted on a Monday for our first launch and on a Thursday for the second. The Monday post did significantly better, but there’s a chance it was because it was the first time we posted, and many of the regular Hacker News people likely saw the second post and didn’t think it was worth looking into.
Tip for multiple launches on Hacker News: For posts that feature the same link that people have already visited, the titles are greyed-out, so they don’t show up as prominently in the forum. This is to encourage people to post fresh, new content.
The first half of the week works well because it gives you time to ride the momentum—possibly even getting picked up by newsletters that skim through Hacker News like TLDR or other publications later in the week. Consider that the life of your post is only for 48ish MAYBE 72 hours. Posting too close to the weekend risks losing that extra traction if your post doesn’t get an extra boost of interest from people after the first day.
Pre-Launch: Your Checklist
Before you hit that submit button, make sure a few things are in place, otherwise you’ll miss making the most of the opportunity.
- Your Title: It’s your headline, your hook, and your one chance to catch attention. Spend time crafting something that sparks curiosity, not something overly branded or formal. We put this down again because it is so so important.
- Multiple Team Members: If you have more than one team member, get them involved. Have them draft their own comments to engage in the discussion early—this will help stir conversation and build momentum right from the start, and people tend to be curious about posts with a lot of comments on them.
-
Your Product Setup: Ensure that you have a way to track who’s adopting your product once you launch, because a lot of people will be trying it out. For our first launch, we were flying blind on who was coming through the pipeline, and it made it harder to follow up. After that, we quickly set up a light email wall on our website and NOT the GitHub repo we were pointing to—HN rules explicitly say not to email-wall things, so in our case we let the technical crowd go right to the source, and the non-technical crowd wander to our site. It’s also a good idea to set up a drip campaign to lightly engage anyone who tries the product. Something simple like, “Thanks for checking us out—can you let us know how you found us?” in an non-styled email.
It feels more like a personal follow-up, and the conversion rate for responses has been surprisingly decent after a second email in the drip campaign. I would not encourage you to go beyond two emails though – a lot of people are just curious, and you can think of them as now “aware” of your product. They may come back in 6 months to see what’s going on. It feels more like a personal follow-up, and the conversion rate for responses has been surprisingly decent after a second email in the drip campaign. I would not encourage you to go beyond two emails though – a lot of people are just curious, and you can think of them as now “aware” of your product. They may come back in 6 months to see what’s going on.
-
Your People: Have a shortlist of people you can text on launch day to help support your post. Your goal should be to get as many upvotes as possible early on so that it accelerates your placement on the page. Keep in mind—you can’t send direct links to the post (Hacker News won’t count the votes if you do), so a workaround is to send a stylized image of where your post is on the feed with instructions for people to go and find it themselves. That way, you’re staying within the rules while still guiding people to your post.
- Google Search Console: You’ll want to have this set up to make it easy for tracking people’s interest in your project or brand. It can be a bit intense to get set up, but is very helpful for gauging demand, especially after you post on Hacker News. Many people will find a project, and then Google around to learn more about it. I’ll do another post on how to set that up in the future, so be sure to subscribe so you don’t miss that.
- (Optional for closed-source projects) Your GitHub Repo: Make sure your project is as organized and polished as possible before launching. If you’re open sourcing, ensure your repo is clean, your README is thorough, and everything is easy to navigate. Here’s the Onlook repo for a bit of inspiration. If you can, it’s always good to try to get as many stars as you can and potentially even contributors before your Hacker News launch. The more signal from other people on your repo, the better.
- (Optional) Email your waitlist: Depending on what you’re building, you may already have a waitlist. If you chose to email them about your launch, try to include some other information besides just the self-promotion. We used a monthly product update as a way to share our progress alongside the light ask, so that people don’t feel like you’re spamming their inbox. We sent the email around 11 a.m. Eastern so that the post already had a bit of traction to climb a bit in the Hacker News feed.
The Launch: Capturing Attention
On launch day, consider your timing. We found that posting around 9 a.m. Eastern time works best—this catches the North American East Coast crowd and possibly some early European traffic. If you want to maximize your reach, maybe try even earlier, around 8 a.m.
Engaging your network is also key. Again, don’t directly link people to your Hacker News post–Instead, encourage your network to search for your post using the title, or use the custom image to share to your network.
It’s also important to line up support from other founders, colleagues, or people in your network who frequent Hacker News. Ask them to not only upvote your post but also drop a thoughtful comment. Comments show that there’s more discussion going on.
We’ve got plenty of other great posts coming soon, so be sure to subscribe if you haven’t already!
Along those lines, Hacker News is all about discussion, so get involved in the comments, but avoid spamming responses just for the sake of it.
Be thoughtful, be genuine, and don’t be defensive. We’ve seen competitors get very combative when they launched their projects, which never lands well. You’re going to probably get some haters – that’s just the internet for you. Acknowledge them, get some discussion going, and move on if they’re insufferable.
Post-Launch: Keeping Up the Momentum
Monitor the comments and answer questions as they come in, but don’t feel the need to flood the thread with responses. Keep your comments valuable and avoid being too lengthy. People will bail out of the discussion if there’s a wall of text on every comment.
If you have multiple people working on the thing you’ve launched, try to take shifts for monitoring and responding. It’s much more refreshing to see a variety of names and comments in the thread.
Also, you’ll see a few different colors on Hacker News—orange for YC founders, green for brand new accounts. If you can get some YC founders to jump-in, it’s always nice to have some orange names in the comments because they add more credibility to what you posted.
LinkedIn and Twitter are the best spots to talk about your launch on the same day, because you can comment below your original post with updates. Screenshots of your star-count for GitHub or your overall ranking on Hacker News are good ideas. The good news with Twitter and LinkedIn is that you can share links to your posts with your friends and you won’t be penalized for them leaving comments and reacting / “liking” the post.
Tip for Twitter: if you have a bunch of accounts like and bookmark your tweet, it will do better in the algorithm.
After your launch, you may want to do it again if it goes well. Keep in mind though, that you should only follow up with a second post if you have something new and substantial to add—don’t launch again just for the sake of staying visible. Know that people can see when the same link has been posted more than once.
Wrapping It Up: Post-Mortem and Takeaways
When a few days have passed, take some time to reflect on what worked and what didn’t. Compare your results with other similar posts—what got attention? What fell flat? Take note of the comments and feedback you received (and what other people received on that day), as this can help you refine future launches or updates.
Metrics to track include both website and GitHub traffic. GitHub’s built-in traffic analytics will show you how many people visited your repo and where they came from. Based on our experience, the lifecycle of a Hacker News post is about three days, so keep that in mind when tracking your success.
Tip for tracking success: Remember when I mentioned Google Search Console? Use this to see how the launch effected your ranking after the launch. You’ll see what keywords people search for, and if they are looking for specifically branded keywords that may link to your site.
Note the spike in searches after each launch
Finally, remember that for open source projects, a little bit of organization before launching goes a long way—people are far more likely to star, fork, or contribute if they see a clean repo… something along the lines of Broken Windows Theory, but for codebases.
Launching on Hacker News is a great way to build momentum and get your project in front of a tech-savvy audience, but it requires thoughtful execution. By preparing thoroughly, engaging your network without spamming, and following up thoughtfully, you’ll set yourself up for success.
Good luck with your next launch, and please let us know how it goes – we’re happy to support your next project, just don’t link to it directly!
If you want to follow along with our journey of building Onlook, we are writing about it on Substack here.
Help us out!
If you feel like you learned something in this article, I would be super happy if you could give us a star! And let me also know in the comments what resonated with you ❤️
https://github.com/onlook-dev/onlook
Source link
lol
