I’m sure you’ve heard the statistic that 9 out of 10 startups fail. How can you win against such odds? Is there a secret startup handbook to read or an investment due diligence checklist to follow? Madewithlove has audited over 50 companies, usually as part of an investment round. Sometimes CEOs sense something is wrong and want an honest opinion.
We’ve seen the inner details of the ones that succeed and fail. In this article, we’ll reveal the secrets.
What is the startup success rate and what percentage of startups fail?
More startups survive than you probably think. In the US, roughly 80% of startups are still active after one year. The flaw in this metric and others used are that they rely on the US Bureau of Labor Statistics data about business employment. When these statistics are defined, the word startup is defined as a small business that has hired at least one employee. This is not a startup in the way that most people think about it, an entrepreneurial venture to validate a scalable business model.
Startups are counted when business establishments hire at least one employee for the first time. — US Small Business Administration
If you are okay with this definition, that essentially includes all new businesses, then you might ask why a 2 in 10 failure rate is so different than 9 in 10 failures. It’s because the latter stat looks at a longer timeline. Many new businesses go out of business within the first 5 years, roughly 50%. And this is natural since, given enough time, every business started in a particular year will eventually go out of business.
Business might start at an 80% survival rate in the first year, but in the following year and every year after that only increases to a rate as high as 96%. After 20 years, roughly 20% of businesses founded were still doing business. After 25 years, it’s roughly 15%. I don’t know about you, but if I created a business and grew it to two dozen employees after that length of time, I’d count that as a success.
Depending on your industry, you might have better or worse success. Looking at US companies founded in the fiscal year ending in 2019, over 600.000 were still doing business the following year. That’s a success rate of 78.1%. Agriculture, forestry, fishing, and hunting has the best survival rate at 88.0%. The information sector, which covers publishing, media, and telecommunications, had the worst at 75.3%. Most IT companies fall under Professional, scientific, and technical services, which found that 78% succeeded. Of 116.000 businesses, 90.000 were still operating.
This growth further shows that success can come in many different industries. Additionally, some industries have little competition and are ripe for disruption. Things aren’t as dire as the naysayers make it out to be. You can still succeed as an entrepreneur. Many businesses, year after year, figure out a way to pay the bills. Some do it by accepting venture capital and others do it by bootstrapping, where they cover all of their own costs. Let’s look at both cases.
Financing via bootstrapping — Flexmail’s case study
Flexmail is an excellent example of building things up. They built their product, a powerful and simple marketing email service, with user input. By building what users want, they are able to keep the lights on. This led to a buyout and that’s when the problems really began.
What happens when two teams merge? Processes, cultures, and codebases need to become aligned, and fast. Uniting teams, strategies, and roadmaps is hard. Legacy code and impending regulation further complicates things.
Although Flexmail listened to their customers, perhaps they listened a bit too closely. The product also suffered from a lack of vision. Fast-shifting requirements meant the codebase was difficult to maintain. The product was at real risk of stumbling shortly after finding some success.
The team was able to bring in outside help to support the evolution of the product. Over three years, dedicated user experience and user interface designers questioned every aspect of the platform. This led to a revised mission, one that could be fulfilled. At the same time, the team began to improve the codebase and processes. Adding retrospectives allowed them to reflect on what they were doing.
By questioning what is working and not working, they could adapt their behaviours and improve iteratively. Implementing a robust continuous integration and continuous deployment pipeline allowed the team to ship more quickly. This, coupled with automated tools to ensure quality, gave confidence that any problem could be met with a solution.
This hard work paid off. GDPR was problematic for many companies but Flexmail took the opportunity to rethink their product. They’ve developed a tool that leans into the privacy law and since then has benefited from that strategy. Their approach to work has also changed for the better and now Flexmail is thriving.
Taking venture capital — Sweepbright’s case study
Taking venture capital is one way to avoid running out of money to build the business. If an idea is not profitable within the first couple months,, then the founders can sell a part of the company in exchange for cash, selling a slice of the pie but growing it at the same time.
Buying real estate in Belgium is incredibly difficult. The market is hot, and the competition is fierce. There are myriad companies that can help buyers find what they are looking for. On the other hand, communication is extremely important for the agencies. If they aren’t on the ball, the buyer will miss the opportunity for a specific property, and they’ll end up fired. Sweepbright built an MVP in 2016 that digitized the entire journey from listing onwards.
They were domain experts and understood the world of real estate, but software as a service was an entirely new challenge. This is a classic startup problem. How can they move quickly when they are still learning the basics? They decided to work with a team to build their MVP and began to hire as time progressed. Experts brought the knowledge to make the right decision when it came time to expand the technology and staff. The MVP was a success, and now the team needed to grow.
Scale-ups have an entirely different problem than startups. They need to shift to a quality-first mindset. Taking care of end-user problems while adding new functionality is hard to balance. Furthermore, these changes need to address real world needs while accommodating legacy technical decisions. The team was able to meet these challenges and has gone on to raise another €5.9 million; each time the pie gets bigger.
Reading tip: Why we prefer brownfield software engineering over greenfield
Why do startups fail?
There are many, many, many — not quite countless though — studies about why startups fail and how to correct for those issues. In the end, the truth is that they decide to stop. They stop working on the project for a variety of reasons ranging from personal health to stiff competition to lack of funds. There are many reasons that startups decide to call it quits, but in the end it’s a decision to move on to something else. Experience allows second-time founders to avoid making the same mistakes as before. This is one reason why startups more often find success with serial founders. Read more about the most common challenges faced by scale-ups and startups in 2024.
The more experience a founder has, the better his or her startup tends to perform. — Benn Stancil, President + Founder @ Mode
Failory, a community of startup founders, has interviewed and analyzed many startups to determine the common mistakes. They classified the errors in 6 categories: marketing including product fit, team, financial, technical, operational, and legal. The ability to deliver a specific solution for a specific problem, product-market fit, accounted for 34% of all cases.
And this should come as no surprise.
Ignoring the customer needs (+ other marketing mistakes)
Image source: https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond
Builders love to build things. Too often engineers focus on creating something cool rather than something useful. To put this into design terms, startups focus on solution diamond rather than the problem diamond.
Companies often ignore true product development activities such as interviewing end-users, using surveys to analyze quantitative trends, validating design decisions via focus groups, and clearly defining the problem with domain stories.
Most founders have read The Lean Startup by Eric Ries but they don’t apply the Build-Measure-Learn feedback loop at a granular enough level. If a company spends 3 months building before they begin to measure and learn, they’ve waited too long. Necessity is the mother of invention, but it’s also the mother of staying in business.
If people don’t need what you’ve created, it’s unlikely they’ll buy it. They also need to hear about it in the first place.
Other marketing failures accounted for another 22% of cases studied by Failory. This includes stiff competition, not providing enough value, user retention, a too-small market, and lack of focus. I would again classify some of this as part of product management.
Lack of experience + funding problems = startup failure
Team problems (18%) and finance problems (16%) were other major factors. The former boiled down to not having the right experience to execute on marketing, business, or technical tasks. The latter included funding problems (the inability to raise VC money) but also included issues where monetization was a factor or profit margins were too small.
In summary, the company will succeed when the product is desired by the market and people are willing to pay for it. This gives the company enough runway (time and money) to revise their strategy and to learn how to scale up.
My startups failed, too — Cuddli’s case study
Cuddli, my very own startup, was a dating app for geeks. At first, my co-founder was heavily focused on the major problems of existing dating apps. They don’t follow a relationship cycle so when you find success, it hurts their business model. By creating a free app with all the bells and whistles, we could monetize the in-world dating experience.
Imagine you’ve been chatting online with a nice person. You decide to meet for dinner. The app helps you find highly rated restaurants and makes the reservation. When it comes time to get ready, the date notifies you ahead of time and offers to hail a ride. Because you both ordered entrées, a free dessert arrives. You can cover the cost of your date’s ride home if you’d like and even send flowers the next day. The business model is one where we’d get a kick back on each of these transactions.
So where did things go wrong? We didn’t do enough discovery work. Although people dating in the US spend billions of dollars each year, we couldn’t tap into it. We weren’t solving a real world problem that these users needed solving. People can find dates with Tinder (where they quickly switch away to SMS or other chat apps with more robust features). They find good restaurants from Google Maps or Yelp. Need a ride? Well, there’s an app for that too.
We ended up building a great, robust chat and date notification platform. The problem was we never built in any monetization. After 4 years spent living on savings and avoiding medical checkups, we decided to call it quits. Over 100.000 people downloaded Cuddli but we ran out of money among other things.
Could this have been avoided?
How to prevent your startup from failing?
Madewithlove has audited over 50 companies to help them in two different ways:
- When stakeholders, CEOs, or investors feel that something is wrong. Perhaps they’ve lost trust in the things the CTO is saying or a key member of the team has recently left and the team is struggling.
- When the team is trying to raise money as part of a seed or Series A round.
- Get advice on how to hire a good CTO for the startup or scale-up
In both of these cases, we dive deep into the team and product to determine what is working and what doesn’t work. The way we do this is via interviews and code review. We analyze the information and organize the results across five pillars:
- Team and leadership
- Process
- Written communication
- Engineering
- Problem and solution
It is important for us to understand this big picture in order to pinpoint the challenges of the company and product. This will allow them to resolve the issues at hand or to scale properly if they receive investment.
We usually see the same trends. We don’t directly look at the financial and business side of things, but we do find repeating patterns that will lead to failure.
5 pillars of every due diligence (technical) audit
Also see our Ultimate Due Diligence Checklist for 2024
Pillar 1: Team and leadership
For team and leadership, there are two key things that might be missing. First, the team needs good psychological safety, the perceived and shared interpersonal risk within a team, i.e. is it okay to fail. According to Google’s Project Aristotle research, this is the number one trait of high performance teams. Individuals need to be able to try things and make mistakes. This will lead to transparency and better results since the entire team can learn from each other.
Second, a culture of feedback needs to exist. Planned monthly, if not weekly, 1-1 feedback meetings should be held to exchange feedback. Almost all managers surveyed by Canpoy (89%) said that these meetings positively impacted performance. We’ve found the same to be true since it gives an opportunity for leaders to hear directly from their employees and make the necessary changes before problems become too serious. Giving and receiving feedback is a skill and it needs to be practiced regularly.
Pillar 2: Processes
Processes are challenging for new teams. Too much process and people feel overwhelmed by bureaucracy, too little and they are lost. The number one process to implement is a retrospective meeting. This allows for all other processes to improve little by little. In a similar way, code reviews or pair programming sessions are missing from technical teams. These, too, are invaluable to improve over time.
Another area that needs attention is often in how companies hire.
Hiring is the single most important decision that a startup can take. Hire slow, fire fast is an adage that you’ve probably heard before. Taking the time to source and vet the right people is important. For example, many startups make their first technical hire the CTO, but this isn’t necessary. Startups only need a CTO when they are planning to raise money or when the team is scaling quickly. If a founder is a technical expert that doesn’t automatically make them a people manager, one of the key skills that a CTO needs.
As the company transitions to a scale-up, the hiring pipeline will become even more important since the temptation to sacrifice quality for who is available is ever present.
Hiring the wrong technical profiles early on in the venture might sacrifice the whole effort. I believe early stage companies should only work with experienced people and hire juniors only when they have hit the growth stage. — Andreas Creten, CEO and Founder @ Madewithlove
Read more about our guide to hiring and seniority in software development teams.
Pillar 3: Written communication
When it comes to written communication, startups we audit receive the worst marks. Generally, they’ve been “moving too quickly to write things down.” This is no excuse. Because startups have many key non-replaceable personnel, it’s even more important to document, document, document.
What if one of these people left the company? Taking time to document technical and non-technical processes, instructions, and domain knowledge is important to a growing company. By creating this information early, and becoming a knowledge-first organization, new hires will be prepared to contribute value immediately.
Pillar 4: Engineering
If you are a technical company, engineering work is core to the business. Here the mistakes are nuanced to the specific product but there are still some things that businesses can check.
First, a robust continuous integration and continuous deployment (CI/CD) pipeline can be used to automate the rigmarole of releasing new versions. Your engineers should focus on removing roadblocks that prevent them from delivering value to end-users each and every day. The CI/CD pipeline is the main way to address these obstacles, complete with automated tests and other quality checks.
Additionally, we often find that teams are pressured into ignoring legacy code. All products are expected to have some code that is outdated. However, technical debt is a trade-off between doing things the right way and taking a temporary shortcut — keyword temporary. If companies don’t give time for engineers to clean up after themselves then they will eventually hit a wall.
As soon as you commit code, it is legacy code. — Emma Fabre, Software engineer @ madewithlove
Pillar 5: Problem and solution
Problem and solution focuses on each half of the Double Diamond design model. This is where we document the things we see going wrong in the discovery phase and how that’s communicated to teams tasked with creation.
The main problem here is often a clear and well documented vision. Workers need to understand where the company is going so that they can make the best decisions today. Coupled with this is the need to communicate the path clearly. This is best done by an outcome- or problem-based roadmap. Often, companies we audit have either no roadmap or one that is made in PowerPoint.
Structuring a roadmap that covers the context, has explored potential solutions, and creates space for engineers to prototype is difficult. Informal task prioritization via Highest Paid Person’s Opinion (HiPPO) rather than a formal method such as Weighted Short Jobs First further complicates things.
Secondly, we often see little quantitative and qualitative research being done. Teams love to build solutions, but they don’t bring in the customer early enough. Validation should occur at every step of the way. This aligns very closely with results from the analyses above about why startups fail.
Companies spend their entire engineering budget on one idea and then when they put it in front of customers there are a lot of requests for small changes. They chase one or two people thinking that if they just add this next feature they’ll suddenly make it big. That overnight success takes years of grinding and careful, thoughtful analysis.
Madewithlove’s approach
At madewithlove, we cultivate teams and their products. We do this in two ways.
With greenfield projects, where no code has been written, we come in with an experienced team and then help the company hire as we slowly phase out. It takes time to build a team before you can build a product so you can borrow ours for a while. We think of this as ghostwriting startups.
Where existing teams are struggling, we take on the role of Gordon Ramsey in Startup Nightmares. We always arrive with an approach on both the leadership and engineering sides. With the leaders of the company, we shape the vision, roadmap, and processes. We develop the culture and ensure people are getting enough feedback. Our engineers help create high quality, but well-scoped, code. They configure a CI/CD pipeline which allows for consistent delivery of value. They gain a consensus on a definition of done that includes written documentation.
The stories I told before of Flexmail and Sweepbright are proof of our approach. We helped these companies thrive. You can learn more about exactly how on their case study pages. If you aren’t sure how your startup is doing, we are here to help. Contact us today to learn more about technical due diligence.
Member discussion