DEV Community: Daniel Farrell

How to crush your Hacker News launch

Daniel Farrell — Thu, 19 Sep 2024 21:30:29 +0000

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:

Show HN: For projects you’ve built yourself.
Regular HN: For other discussions and other content.

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

16 hard truths from the first 6 months of building an open-source devtool startup

Daniel Farrell — Mon, 26 Aug 2024 19:44:29 +0000

Since starting Onlook back in January, I’ve met quite a few people who are toying with the idea of entrepreneurship as their next career move, and I felt like sharing some of the (hard) truths that I’ve experienced while working on my own startup.

This is by no means an effort to discourage people from pursuing entrepreneurship, but a list I would have appreciated while I was in the phase of thinking about starting a startup. I felt many of these truths while I was working on Wanderlift, my first serious venture, but as I’ve matured and seen more of how the world operates, I can now feel confident that these are reality.

Obligatory disclaimer – All of these points are from the lens of building a venture-backed startup. There are plenty of other forms of entrepreneurship (like building your own embedded ops company – shoutout to Hup), but even so, there may be some relevant overlap for any kind of side-hustle.

16 truths of entrepreneurship

No. 1

People do not want to associate with companies that are not either a) cool or b) winning – You must be perceived as doing well. In harsher words, people don’t want to associate with losers, so don’t come off as one.

One way you can prevent being perceived as a loser is by avoiding what I call “JV” a.k.a “Junior Varsity” behavior. It’s totally ok to make mistakes but try your best to quickly correct them. Make the mistake once, and try your best to never make it again.
Try to excel at your professional behavior. People tend to be impressed when you have your life together and are tight with your process of doing anything. This is like the Broken-windows theory of your professional life – presenting well in one aspect of your life helps people assume that other parts of your life are going well too.

No.2

You cannot “will” something into existence – it must be earned…

There is a lot of “playing-house” in startup land that so many of us are guilty of. Paul Graham wrote about this concept, but it boils down to “don’t mistake motion for progress”. So many people think the first thing you need to do with a project is get all of this other logistical BS setup before you can launch or do anything.
I continuously come back to YC’s advice that the only two things you should prioritize are 1) talking to users and 2) building product. Everything else – and occasionally, even building product – is “playing house.”
Doing anything is better than thinking of doing something, so go forth and earn what you think should exist.

No. 3

…and you don’t know what you can earn unless you try.

You’ll overthink when the perfect time is to launch. You’ll tell yourself that just one more feature will be the winner for your company. The truth is, your ego is getting in the way of you learning a big big lesson by putting an idea out into the world.
You should try to throw your business into the fire as much as you can. Especially because people will resonate with your message and mission more so than your actual product for much of the early days. It’s why I’ve come to realize that the title and logline (one-liner) of your startup (something I picked up from Save the Cat) are so critical – it’s what gets people fired up. This is a great article on writing loglines for scripts, but this amazing writeup on category design is a great reference for thinking about the logline of businesses.

No. 4

Entrepreneurship is purely rejection. You have to be prepared to be rejected constantly. Constantly. Again. And Again. And one more time. And Again.

You will be rejected by investors, by potential employees, by customers who signed up and said they’d be interested in your product, by everyone.
Most of entrepreneurship is just following up with people to actually get a rejection. At least a rejection is some peace of mind that they’re not interested, but sometimes you may just have a moment of opportunity and surprise where someone extends themselves to help you, or says “yes”.
Nike recently put out an ad that captures the mentality: Winning isn’t for everyone.

It’s totally true with entrepreneurship. Have I (me, Daniel) won? Hell no! But I have to operate with this mentality because it’s the only way things will be achieved. See Point 2.

No. 5

Because you’re always pitching, you must be optimistic (Point 1).

People invest their time, reputation, and resources in you for the possibility of your success, and it’s up to you to convince them. People don’t invest in neutrality, and they definitely don’t invest in pessimism.
Your only role is to be the most optimistic about your idea because you’re the only one who is relentlessly optimistic about your vision and your idea.
This comes with the caveat that you should not pitch to customers the first time you meet them. You should be “discovering” their problems and opinions, but for everyone else who isn’t a customer, you should be optimistic.

No. 6

The types of people that build companies are the ones that build companies (Points 2, 3).

The people who build companies don’t talk about building a company someday, they don’t fantasize about the lore of a company, they don’t go to every startup event in their city. They actually do the thing and make something.
This is totally and entirely obvious advice, but you will never have a grip on what actually works if you don’t try it yourself.
How do you make something? You just do something. Right now. Get that Twitter handle. Write your first LinkedIn post. Doing anything is how you do the thing. You’ll need an audience for whatever you have, so start building it right now.

No. 7

If you run into a roadblock, it’s likely because you’re afraid to “Just…”. Just do X. Just do Y. Just email Z. I have to remind myself this all the time.

If you are serious about building a company, you should get on YC Cofounder matching immediately. It will take you months to find someone who is compatible, and you need to let the world know that you want to be someone that builds companies.

All of the people I’ve met who are shy about getting on YC Cofounder matching are not serious enough about building a company. It is the easiest thing you can do to start meeting other people who have self-selected to be an entrepreneur.
I’ll emphasize again, that even if you have a cofounder in-mind, YC Cofounder matching is a great pipeline for potential talent, so you must get on the platform. It is JV to not even try to get in front of other smart people.
People’s willingness to take this very very low and approachable step is the biggest indicator of whether they’re playing house with the idea of startups.

No. 8

Losing touch with who you’re solving a problem for is very very easy. It is more important to know your customer than building something.

You really should try your best to be in continuous contact with your customer, even if you think you’re your own customer. This is a very hard lesson I have to remind myself of all the time.

No. 9

Startups are in the business of urgency – If you’re not feeling the urgency, you either need to be talking to more people, or trying more experiments.

There are plenty of other ways to build a business, but if you chose the VC money route, you need to get learning. Try Reddit, try Hacker News, try calling a friend, try texting a coworker, try LinkedIn messaging another founder. Try anything to learn more.

No. 10

Despite the need for urgency, you will burn out if you don’t occasionally take breaks.

It is so much more fulfilling to get back into work after a half-day or a weekend break.
I still am learning this lesson because at every moment I think I need to be doing something to move the needle forward for my company. This coffee-break has been one of the few days that I’ve not forced myself to actively work on Onlook, and yet I still ended up putting 2 low-pressure hours in.

No. 11

Your company won’t live or die by major big decisions, but mostly through the culmination of many smaller decisions (Points 2, 3, 6).

The types of decisions you make should be dramatic enough to get you enough data to know where to go next. It’s why talking to users is helpful – sometimes just talking to 3 people will get you a ton of insight into how much someone cares about a problem and whether it’s worth solving.
You’ll probably worry much more over small decisions than the larger ones, so try to focus on larger, higher-impact decisions.

No. 12

There is a baseline of performance people look for in assessing your startup. Do your best to hit that baseline.

This is one of the reasons why San Francisco is the most successful startup hub: you can look around and understand very quickly what successful startups look like and emulate them.
Being adjacent to other startups that are performing in this baseline is signal in of itself – getting referrals from other builders to investors, partners, and companies are a great way to show you're on the right level.

No. 13

The most important thing you need to do is likely what you’re avoiding.

A great way to not “play house” is to tackle what you’re avoiding. Playing house will always be easy to do, but the hard stuff is where you learn things.
You should practice lifting your “do hard stuff” muscle as much as possible so it becomes habit. You’ll feel a sense of adrenaline and relief when you try something hard – try to get that feeling as many times as you can during the week.

No. 14

Raising money is the most irrational, frustrating thing you’ll do.

You’ll wonder why you have to go through the process. You’ll wonder how some people can be so bad at their jobs of getting back to you. You will have to grit through and smile through the process of dealing with the widest array of characters and personalities – both good but mostly bad.
You will need to talk to over 100 people and be ready for every one of them to give you some reason as to why you’re not a fit for their fund at this time (Point 4).
Investing is not the same as building – keep this in mind with every conversation you have with an investor. That’s another way of saying the advice you’ll get from investors will very likely be normie common-knowledge unless they are specialists or have built something before.

No. 15

The biggest challenge you’ll face is maintaining your own belief in yourself.

The belief that you’re capable of overcoming hardship, that you will continue to persist against all of the rejection (Point 4), and that you’ll remain optimistic (Point 5) when things are not working out.
The belief that even though there will be so so many bad days, you’ll wake up and do it again tomorrow. The beatings will continue until morale improves.
This ties to many of the themes I’ve written about in the past, including:
Don't be your first rejector
The person you choose to be right now

No. 16

Finally, the only way to do entrepreneurship is your way.

I have read so so so much advice, listened to so many podcasts, watched so many videos on everything related to startups. Some of the advice is applicable, but you should think of startup propaganda as a source of inspiration, not gospel you’re prescribed to follow.
For example, if you want to “fake” the way you build your company by pretending to be someone else and it gets you results, then by all means do it.
Treat all of the advice out there as frameworks and ideas that might be helpful but lean on believing in your own ability more than the hacks and tricks other people encourage you to follow. After all, at the end of the day you’re the one that has to go and do the thing.

I’m sure there will be many other truths to come in the months ahead, but I hope this helps other current and aspiring entrepreneurs navigate the wildly chaotic and fulfilling journey of making something.

If you want to follow along with my journey of building Onlook, I’m writing about it on Substack here.

Help me 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

Why we ditched Linear for bug tracking

Daniel Farrell — Mon, 15 Jul 2024 23:14:21 +0000

I love scaling up systems – There’s nothing quite as satisfying as knowing something you hacked-together is working and helping the team rather than creating too much process.

But making familiar software takes a ton of testing.

It’s part of the reason why the best product teams like Apple and Linear take time to release things – the first draft of a software product will inevitably run into a lot of wonky edge cases that cause stuff to break, and you need a team of people to try to simulate as many of those edge cases as possible before you send it out to hundreds of thousands of people.

One way you could simulate the wonky edges is to use a tool like Synthetic Traffic, but another is to just get as weird as you can with the app you’re building.

Just tracking bugs is a challenge in of itself, regardless of the tool you use. Couple that with the need to fit it into the minefield-discussion of how your team should manage tasks (Coda? Linear? Jira? Notion??), and you’re looking at a really gnarly and enraging debate. It’s the difference between sipping a nice glass of fresh squeezed orange juice and getting a vat of vodka-Red Bull-pickle juice-sriracha dumped on you – it’s aggressive, sour, spicy, sticky, and a non-ideal Tuesday night.

There are infinite combinations of how people track bugs, but I wanted to share our system we use today because it may inspire small teams to focus on what will get more things done today, rather than find the perfect system to scale before you really need to.

Losing Linear

My cofounder, @kiet_onlook, and I originally started working in Linear with our company Onlook.dev, but had a realization with our workflow: As much as we love Linear, organizing all of our bugs was actually getting in the way of getting the work done.

We needed to go simpler.

Kiet and I communicate asynchronously in Slack and Google Docs, so we needed a source of truth for bugs that was super easy to understand and organize. Ideally, the source of truth wouldn’t have to be another thing we need to check or log-into or have to remember where to find.

We started in Slack with our #bugs channel, where we came up with a color system using four bug emojis that communicate what prioritize at a glance.

butterfly = Feature request / larger UX improvement.

beetle = Small improvement / smaller UX suggestion / cosmetic adjustment

ladybug = Medium issue <-- default if you don’t know what to rate

fly = Shit / broken / crashing / really bad stuff

Why did we assign each of these roles to those specific emojis? It’s mildly intuitive, and if you look closely, it’s a color spectrum from good to bad.

🦋 Butterfly / Blue – Good! Improvement, suggestion etc.
🪲 Green Beetle / Green – Small improvement / cosmetic adjustment, not too critical.
🐞 Ladybug / Red – Bad / needs attention.
🪰 Fly / Brown – Really bad / poop / critical to be addressed.

Catching bugs in the field

What does the bug marking system look like in practice?

For example, let’s say that Kiet put out a new release, and I came across a bug while testing. I’ll drop a new header section in our Bug Tracking Google Doc for the date (an easy proxy for the likely version we’re testing) and make a checklist of what I come across. At the beginning of each point though, I’ll add the right bug emoji to make it easy to organize at a glance.

Kiet or I will often batch bug requests into groups, because the Butterflies (feature requests) can be put off for some time while Flys (Critical issues) need to be addressed much sooner.

And because this is done in a Google Doc, we can discuss, and re-batch bugs as needed depending on how long we think they could take and how urgent they may be. The Google Doc also gives us a long record of feature ideas we’ve come up with in the past, so as we plan what to release next, we can go Butterfly hunting with CMD+F and start a new list of features we want to prioritize.

We have a #bugs channel in Slack where we originally were tracking these, and most of our conversation has shifted from the #bugs channel to the Bug Tracking Doc for asynchronous things, but the #bugs channel is a helpful place to track conversations without crowding the doc’s sidebar. Also, because Slack is great for sharing screenshots and files, it can be better for providing richer context than Google Docs.

As an additional boost to our bug tracking, I set up a Zapier automation that will send a bug to our document if someone reacts with a bug emoji on a message.

The Google Doc is our source of truth, and it’s an easy to format checklist for us to work through, while we use the #bugs Slack channel for active back-and-forth discussion on bugs.

Because each bug in the Google Doc has a link to the Slack message, we can continue to reference the discussion while keeping the original checklist clean with the general idea of the bug, and none of the noise.

Don't over-optimize too soon

If you’re just starting out on a project, my biggest advice would be to go simple with your tools. Every second you spend trying to build out a fancy system is time and energy spent away from either building a product or talking to people who you’re building for.

Paul Graham wrote about the idea of “Playing house” in his essay Before the Startup and it’s a continued reminder that systemizing things or getting too complex with how you set up your processes is just not important in the early days.

We are big fans of these tools that help teams work together effortlessly, yet until we bring on more people outside of the founders, we need to keep things lean. If you’re asking yourself the question of “where do I put this ticket?” too often because you set up some project management tool that has way too many features, you may need to go simpler.

You’ll have plenty of time to systemize your process later, but for now, try catching bugs in an easier format.

Help me out!

If you feel like this article helped you, I would be super happy if you could give us a star! ❤️

https://github.com/onlook-dev/studio

Also, I'm curious how you track bugs on a super small team. Let me know!