Should I wait for a big “launch day" to release my open-source startup, or do it now?

You've been working tirelessly on an idea for an open-source project, getting it ready for the big wide world. So far, the feedback (if any) you've collected was restricted to very few.

Now a question begins to surface for many builders, do you plan for a big "launch day" and try to release your "perfect" product, or do you release your open-source project as soon as possible, flaws and all?

Launching can take even more courage when it comes to open-source because you are releasing a product and a whole codebase alongside it.

Let's look at some of the pros and cons of waiting to release for a "launch day" vs. releasing as soon as possible.

Pros of waiting for a launch day to release:

• You'll have more time to build and improve your code so it can live up to your vision
• You can build a more tangible technical advantage before your competitors could easily copy it or steal your idea
• If you already have a community/following, you can build up anticipation

Cons of waiting for a launch day to release:

• Likely there won't be a big response, especially if you don't have an extensive network
• You'll stress and worry about aspects and features your users might not care about
• You'll be later to the party, and competitors may be faster
• It will be harder to adopt your codebase for an open-source release because if you spend more time developing in private

Pros of releasing ASAP:

• You'll get feedback earlier 
• You can stop pouring resources into building features your users don't care about
• You can funnel those resources into features that matter 
• You can have a first-mover advantage over competitors 
• You can start to build a community of users around your product and identify advocates and influencers who can help spread the word
• Your project will be open-source from day one, meaning you would have to reconfigure less stuff, search for fewer API keys in your codebase, etc.

Cons of releasing ASAP:

• Some people will see a crappier version of your project
• You might release an unstable version of your project with lots of future changes in APIs and SKDs which could lead to a bad developer and contributor experience

Looking at the list, you should be able to guess what we recommend - release sooner rather than later. However, we don't mean open-source the roughest version of your code and then tell everyone under the sun about it, and here is why: 

Launching should not be a singular event.

Ideally, you'll launch, again and again, refining and improving your project throughout its life cycle. That said, a launch day where you fire on all your own, your networks’, and PR platforms that your OS project is live happens once. So you should be more careful around this type of launch. 

That is why we recommend you consider several essential launches and milestones where you keep bringing your project to a broader audience.

1. The silent launch

Get your project out there, whether it's just a website with some simple info, a sign-up form for beta users, or directly open-sourcing your first version on GitHub, rip off the bandaid and allow people to find you, get in touch and learn about the project.‍

2. The close network (family, friends, peers) launch

Reach out to your close network and get the first version in front of them as soon as possible. Ideally, you have some people who represent your target user, but if not, don't let that stop you. Remember, the feedback you receive from your close network could be pretty biased, though, and can only get you that far.

3. The community platform launch

You can choose one or several of the many community platforms to find and launch to users that match your target audience and won't sugarcoat feedback. From engaging with content on Twitter, Reddit, DEV.to or joining groups on Discord or Slack, finding willing users to test your open-source project, especially developers, is not that hard. Devs usually love to try out new things that could solve a pain point for them and also like giving feedback.‍

4. The “Launch Day” (e.g., media, PR, event, and  extensive network)

When you feel like you have reached a point at which feedback is the same, and you are building the right feature set, you can start to plan a more traditional "launch day." Sometimes, it helps to have a deadline where you want to do a more public release to add more pressure and speed up development. During this time, you can and should keep up the dialogue and testing within your community to get ready. You can activate your wider network, reach out to relevant media and use all your platforms to announce your product on a specific date, maybe around a significant event. 

5. The continuous launch (keep launching in your community)

Once you have publicly launched, things shouldn't change regarding your user involvement and constant interactions. With new features or improvements rolling out, you should have a mindset of continuous launches. Have a new application for your product? Great. You can treat this as a launch and release it to your different communities and sites like Product Hunt or Hacker News. 

How we keep launching at crowd.dev

At crowd.dev, we were definitely a bit uncomfortable with the MVP we shared with our close network and onboarded our first beta users to. There was barely anything there, but it helped immensely in focusing us on building a product that DevTool companies wanted. There were features we thought would be popular, which we altogether scrapped after watching and talking to users. 

We gradually grew our beta waitlist and onboarded users while continually refining our product. We discussed it more on our own social channels like Twitter and LinkedIn and consistently added helpful content to our blog. We open-sourced crowd.dev silently, not telling anyone outside our existing community about it yet, but it was out and it forced us to get it open-source ready early on.

Simultaneously we started to get a clearer vision, based on feedback, at which point we would want to do our bigger launch. We defined a tight yet feasible roadmap and picked a day where we would tap into our network, take part in a big tech event, and do a press release to let as many people know we were live and open-source. This is keeping us accountable but still giving us time to refine a few elements we need, including certain features and getting clearer on our monetization strategy, for example. 

The benefit of launching to users in a smaller way already helped take the pressure off our "launch day," and we were much less dependent on it to get a boatload of users and feedback. 

Importantly, we know our launching is not done once the press release is out. We will continue to launch again and again to our growing community, whether it be a new feature or a side growth project we are working on. A new feature can be a whole new round of ProductHunt or HackerNews launches which will help us to keep growing. 

The wrap-up

• Don't think of launching as a singular event; it happens again and again in different versions.
• Don't let your classic "launch day" be the first time your target audience uses your product. 
• Do plan for a "launch day" as one of your launches if it suits your OS project, here it helps to get some significant features down before going to the media and press. ‍
• Do focus on building a community around your project as early as possible so you can mobilize and grow from them continuously and keep launching across communities and new community members with every new feature or project you release.