It takes more than a cool idea to make it in today’s startup world. For every success story, there are dozens of failed attempts. But there are ways to avoid becoming another statistic. Usually, when startups fail, they fail for trying to do too much at once. Frankly, it’s to your advantage to not try and out-dazzle the competition when making your grand debut.

It doesn’t matter how big your war chest is or if you’re an alumnus of Y Combinator or 500 Startups or even if you have an insatiable drive to be the next Elon Musk or Mark Zuckerberg. Don’t get me wrong, those things help; they help a lot. However, what’s really going to put you on the road to success is the basic philosophy that Eric Ries (my hero and technology genius) lays out in his bible, The Lean Startup: Keep things simple when first starting out.

This is the way I modeled my own mobile and web development company, STRV, and can personally attest to its success rate. Over the last decade, I have worked with hundreds of startups on the U.S. market. I can usually gauge within seconds of reading a proposal whether the idea has serious potential or if it will crash and burn among the thousands of other submissions the Apple App Store and Google Play get on a monthly basis. More often than not, the ones that are successful are the ones that start lean.

“Often times startups fail simply because they don’t launch lean enough. It’s easy to get caught up in building all the cool features you imagine your product should have. But ultimately, you’re playing a guessing game,” explains Brandon Asherian, whose STRV-developed fantasy sports app, START, is gearing up for release.

“By launching with the most basic, core functionality of your app, you can then build efficiently. You then iterate and build the new features people want,” he adds. “Launching lean helps you save time, save money, and figure out what you don’t know right away.”

Asherian hits the nail on the head. Like most of my clients, we share a similar vision. (Though, the startup gene runs his family. His cousin and mentor is Tinder co-founder Sean Rad.)

Serial entrepreneur Razmig Hovaghimian, another STRV client, offers different advice: “A CEO’s number one job is not to run out of money until they hit product-market fit at scale, with enough capital to cushion downturns.” Hovaghimian sold his video-streaming startup Viki to Japanese e-commerce giant Rakuten for $200 million a few years ago. He is now working with STRV to develop and design a local news company called Ripple.

“My take is that you can’t make sure a startup will work. The vast majority will fail,” says Hovaghimian. “If I had to focus on what would help a startup’s chances of success, I’d say it’s team chemistry, an obsessive user base and a strong unit economics at scale.”

From my perspective, there are seven key reasons tech startups fail, including the points mentioned by Hovaghimian and Asherian. Steer clear of these when launching, and success will be well within your grasp.

1. Don’t produce a full product. Go with the MVP, always. This cuts to the chase of Reis’ Lean philosophy. Many startup founders who have come to STRV over the years want their product to have all of its intended features before launching. This is a mistake. As Reis reiterates in his book, develop an MVP to begin with and focus your attention on testing basic assumptions and core functionality.
2. Don’t go mobile. I suppose you wouldn’t expect to hear this from someone who’s running a 150-person mobile development shop. But I’m a huge fan of transparency, and I’ll be the first to admit that buying mobile users is extremely expensive. One download can cost between $3 and $4. More troubling is the fact that 20 percent of users will never open the app they downloaded, while another chunk will never effectively register. You can go up to $20 or more per active user, with those figures doubling at Christmas time. Mobile development is slower and, thanks to the Apple review process, a much less flexible way of development than web. If it is not 100 percent necessary, I would advise against developing native apps for as long as possible. Apps are great and a very convenient channel for your users to interact with your service — provided you have users. If you don’t, start with web.
3. Don’t waste time on the UI. Having a beautiful UI shouldn’t be a selling point. It won’t help you with distribution. If you release an app with a beautiful UI, you will get zero extra downloads. From a user standpoint, UI is not important. Focus on the UX instead. Users care about the actual product. They care about the service.
4. Don’t take longer than two months to launch. When you spend time in development, you learn nothing about your users’ needs. You should release as soon as possible, even if you haven’t gotten all the bugs out, because users will tell you what features are important for them and which bugs are critical. Basically, if you aren’t ashamed of your product at the release, then you waited too long.
5. Plan for production to be more expensive than you think. At STRV, we can immediately foresee what things will cause delays and like to remind our clients that everything takes much longer than you plan when it come to software development. Factor this into your launch schedule. Make sure you have enough cash on hand to see you through the first two years of your startup.
6. Don’t expect users to download your app. Don’t expect users to download your app on their own. As I like to remind clients, distribution is king. If you don’t work at boosting your app’s appeal, no one else will, and your app will languish amongst the competition. What I have found most helpful in avoiding the so-called “Mobile Slap” is organic traffic, paid installs, influencers and (lots of) App Store features.
7. Don’t over-engineer your product. You will lose critical time this way. Engineer your product to meet the current needs of your users. You can always go back and fix things later. We once over-engineered backend for an app that was supposed to be able to support 10 million users. We ended up amassing just a couple of hundred users in the first week that we launched. What did we learn? Always align the technology with the current (not future) needs of the business.