It's more nuanced than whether you release early or late. I've noticed a lot of startups that release early because "well, that's what you're supposed to do," but then the feedback comes in and they're ill-equipped to deal with it.
Release early when you can release often, but not earlier. Often this requires some meta-thinking about the space your app is in, the alternatives you may need to switch to, and how easily you can turn on a dime. Good design, in other words.
Another thing you can benefit from is good infrastructure and processes for listening to users. As an extreme but perhaps strawman example, in some consumer-web spaces there's little point in releasing an app without being able to A/B test. Build that capability in before you launch.
"Release early, release often" helps evoke the right mindset around launching: save your A game for the time after launch, not the weeks before. Don't build up the launch. Don't set a deadline, round up the press, create an embargo, and work unsustainably late hours to meet the deadline. That way you'll be tired when launch happens. You'll have a celebration, folks will ease up for a day or week, some will even take vacation, until eventually someone notices that nothing happened. Instead, focus on the process. Be blase early on: "This ol' thang, yeah we develop in public, and release all the time." You aren't done when you launch, you're just getting started. Ramp up the velocity after you start getting noticed, because now you have less room for manoeuvre.
Whatever you do, don't focus on the first half of "Release early, release often," and ignore the second.
And I would add, release early and often only if releasing is easy. I worked in an shop that was trying to be "agile" with an enterprisey consultingware kind of product. They tried to release every 6 weeks or so, but the releases were complicated to deploy and deployments were additionally complicated by their customers' own change management processes that made the releases flow like cold molasses.
They ended up with releases backed up two or three cycles at some customer sites, customers who could not cope and only wanted every other (or every third release), which created a support nightmare and customers who felt the software was in a never ending state of flux.
So, if your releases involve a "download this zip file and extract it here" kind of process, it's a lot more feasible to do the early/often thing. If your releases require dispatching an engineer on a site visit, maybe not such a good idea.
Release early when you can release often, but not earlier. Often this requires some meta-thinking about the space your app is in, the alternatives you may need to switch to, and how easily you can turn on a dime. Good design, in other words.
Another thing you can benefit from is good infrastructure and processes for listening to users. As an extreme but perhaps strawman example, in some consumer-web spaces there's little point in releasing an app without being able to A/B test. Build that capability in before you launch.
"Release early, release often" helps evoke the right mindset around launching: save your A game for the time after launch, not the weeks before. Don't build up the launch. Don't set a deadline, round up the press, create an embargo, and work unsustainably late hours to meet the deadline. That way you'll be tired when launch happens. You'll have a celebration, folks will ease up for a day or week, some will even take vacation, until eventually someone notices that nothing happened. Instead, focus on the process. Be blase early on: "This ol' thang, yeah we develop in public, and release all the time." You aren't done when you launch, you're just getting started. Ramp up the velocity after you start getting noticed, because now you have less room for manoeuvre.
Whatever you do, don't focus on the first half of "Release early, release often," and ignore the second.