This is a chapter from the book Starting & Sustaining which is a system to help you build and launch a web app with less pain and fewer mistakes. The entire book is free to read on the web.

You can also buy the book and additional resources which includes the digital version of the book, the audiobook, a playbook, and hundreds of dollars of discounts.

Launch way too early

If you’re not embarrassed by the first version of your product, you’ve launched too late.

Reid Hoffman, Cofounder of LinkedIn

Launching is incredibly important. But a big splashy launch day is a waste of your time. Putting your application in the hands of real people is the most important thing you can do.

Before we dig into this, I want to dispel the myth of launch day. Certainly, launch day is not meaningless–it’s a significant milestone for any team–but the notion that it needs to be a flashy event with lots of traffic, attention, and perfectly timed media announcements does more harm than good. If you were to have a spectacular launch day and an influx of traffic, the risk of a major bug or even downtime could completely negate the benefits of your snazzy event (but we’ll address that with the next chapter, which is about launch day strategies).

You deserve to celebrate your launch, but keep in mind that it’s a fairly brief moment in the grand scheme of things. It’s tempting to fall into the trap of wanting your launch day to be a perfect event with media coverage and massive amounts of attention. Remember, within forty-eight hours your traffic will settle down to normal levels, and it’ll be back to business as usual. What you do after your launch determines whether you’ll succeed.

Don’t think of it as launching a completed product, but rather a foundation from which you can gather feedback and bring in the revenue that will ultimately fund your vision. In that context, launching too late often carries greater risks than launching too early. You don’t want to launch garbage, but you should launch before your product has all of the features you think it needs. Absolutely nothing helps invigorate your team like releasing their work into the world. In a way, this is just the first launch of many: every new feature has its own launch day. This first one is just you dipping your toes in the water. You’ll eventually get launching down to a science.

As a startup, your biggest risk is spending your limited resources on the wrong things. Premature scaling. Features no one will use. Internal tools you don’t need. Those are problems you shouldn’t worry about yet. No matter how confident you feel, there’s no way to have all the right answers until real customers start using your product. You introduce more risk with every day you don’t launch.

While there are some variations, your launch date--whether early or late--doesn’t really affect the pace you can develop new features. (The timing of your launch may affect which features land before or after it, but the pace remains the same.)

The instinct to add more features before launch often stems from the assumption that new features carry only benefits and no drawbacks. But I think it’s the other way around. Every feature and delay carries significantly more drawbacks than benefits at this point in your product’s life cycle. Until you receive real-world feedback from paying customers, you simply don’t have enough information to make the best decisions. Moreover, every day that you’re not generating revenue, you’re inching towards failure.

Developing new features before launch is risky because your feature priorities amount to little more than a guessing game since you don’t have customer feedback.

Sifter was missing a few features when we launched. It was coming down to launch time and we had to choose among themes, search, file uploads, an API, or milestones. We launched without any of them. We added some shortly thereafter, but launching without these “critical” features didn’t kill us or ruin our launch.

I felt incredibly uncomfortable telling people that Sifter was ready, but as it turned out, it wasn’t a big deal. A handful of folks asked us for some of the features that were missing, but that didn’t stop us from launching. Sure, we may not have had every bell and whistle, but we were making money sooner rather than later. And that money helped fund the work on those features.

If you look at the plot of our average daily revenue relative to our major feature releases, you can see that there was virtually no growth directly tied to a given feature.

While some features are essential to the long-term life of a product, there aren’t any silver bullets. If you were to look at Sifter’s growth over time, you’d notice that there aren’t any spikes when we’ve added significant features. Just slow and steady growth.

Nothing is more important than getting your product out the door. Launching gives you feedback, revenue, and momentum–and that’s when the real work starts. Celebrate the achievement, but don’t obsess over the event.

Support Starting & Sustaining

This chapter is just one piece of a much bigger puzzle. Starting & Sustaining is a complete system to help you build and launch a web application with less pain and fewer mistakes.

The Package

An illustration of the checklist, book, and spreadsheet.

The Audiobook

An illustration of Starting & Sustaining on a mobile device audio player.

The Book

An illustration of Starting & Sustaining on an iPad.
An illustration of an envelope with a wax seal.

Once-a-month emails Focused emails on SaaS topics like email, security, onboarding, pricing, and more.