Skip to main content

Why Startups Fail: A Case Study

Robert is a Silicon Valley entrepreneur who provides business and technical consulting services for startups and small-to-medium companies.


For the past year, I’ve been following a new web business. I initially had high hopes for the business, but as time went on, I lost faith, for reasons I’ll discuss below. I may be proven wrong, but today I strongly believe this business is going to fail.

From the outside, the problems of this business are glaringly obvious, but the founders seem oblivious. That’s why it’s essential that founding teams have an experienced and sometimes critical team of outside advisors.

In this article, I’m going to showcase the various failings of this particular company, and ways they could be avoided.

Throughout this article, I will refer to the business venture as "the company" or "Zyzzy" (not the real name), and its founders as "the team." I’ll refer to the website itself as "the platform."

Non-Traditional Funding

The traditional mechanisms for funding a startup are difficult, time consuming, and often painful. Typically, founders invest their own time and money to develop a proof-of-concept, and build a business case. They then begin presenting that case to potential investors: angels or venture capitalists.

The investors will ask very tough questions and harshly criticize the business plan, forcing the founders to rework things again and again. Throughout this process, which can take many months, the plan is refined and weaknesses are found and addressed.

Because the process is so difficult, and often fails, many founders are tempted to go directly to small investors using a variety of non-traditional funding mechanisms.

In this case, the company was funded through an ICO (Initial Coin Offering). The team created a crypto-token—which would be used on the platform both to purchase various site services, and to pay site contributors—and arranged for the token to be listed on several cryptocurrency exchanges.

Purchasers were not buying shares in the company. Instead, they were buying tokens, in the belief that the tokens would have some utility, and increase in value.

There are several problems with this funding approach:

  1. The company’s business plan was not critiqued and honed by sophisticated investors.
  2. The team was forced to divide its efforts between building a credible business model for the platform, and a credible use case for the token. The two are inextricably linked, and both must succeed in order for the company to survive.
  3. The team needed to tailor its business plan and pitch to the community of crypto investors, who are not representative of the general audience that the company must reach in order to succeed.

Another problem with this funding method is that it provides only money. With conventional funding, investors appoint a board of directors to oversee the team, provide useful advice, and if necessary even replace team members to assure the success of the company.

In this case, the team has made glaring errors—which I’ll discuss below—but there was no one to oversee their actions and hold the team accountable.

Planning and Implementation

As part of their funding efforts, the team developed a detailed specification and roadmap. These comprehensive documents represented an incredible effort.

Scroll to Continue

Read More From Toughnickel

Unfortunately, this effort ignored the lessons of the last 30 years of software development. The problem with building a platform based on a comprehensive spec is that once the platform is deployed in the real world, fundamental flaws and misconceptions in the spec are discovered. All of the details that were carefully planned become irrelevant, because the platform is not addressing the concerns and issues of real users.

In this case, almost as soon as a beta version of the platform was launched, users began pointing out serious problems with the basic model. Rather than stepping back to rethink their assumptions and address the issues that were raised, the team continued to doggedly follow the roadmap.

To make an analogy, the team continued to build a house even after it was discovered that the foundation wasn’t sound.

In another departure from current best practices, the team released new features in large blocks, with four to six weeks between updates. Modern “agile” development is based on a continuous development and release process, with new features being rolled out very rapidly—often weekly. This allows developers to quickly respond to problems, test solutions, and if necessary, iterate.

Agile development also allows users to see rapid progress, and see their concerns being addressed, which increases enthusiasm for the platform.

The very slow progress on the Zyzzy platform leads me to suspect another problem. I believe (without any insider confirmation) that the team was striving to build very well-architected, robust, and scalable software. While this is in some ways a laudable goal, it’s not the right path in a startup environment. Startups need to get features to market quickly, even if it means cutting corners. If the platform is ultimately successful, the company will have the resources to fix things. And if the platform fails due to market forces or business reasons, it doesn’t matter how well the software was built.

Based solely on the very slow pace of platform development, I strongly suspect that the team did not understand the importance of getting features to market quickly.


The team succeeded in one area. The graphic design and user experience of the platform are great!

In order to succeed today, websites need to be attractive and easy to use. Many startups don’t take this aspect seriously, and lose users because their sites look amateurish and cheap. Score one for the team—they got this right!

A great look and feel, however, is not enough to compensate for a platform that does not meet the needs and expectations of its users.

Listening to Users

Early adopters are essential to the success of any tech business venture. The early users provide real-world feedback on the platform, allowing the team to iteratively improve their initial vision.

The early users—if they are pleased with the results—become the platform’s most enthusiastic salesmen.

In this case, the team created an online “community forum,” separate from the platform, and encouraged users to post their ideas and concerns. In general, this is a great idea. Forums can give the team a way to hear directly from users, and understand their priorities and concerns.


Sadly, that’s where the team dropped the ball. Early users pointed out major problems with the platform, and spent many hours discussing possible solutions—which were ignored by the team.

In the words of one early user, “The community is where suggestions go to die.”

Months went by, and posts by the team made it clear that they still were not taking the concerns of their users seriously. They continued to explain that the platform was still in beta, and was not “feature complete.” They ignored the fact that the features they were developing did not reflect the needs or priorities of their users.

Outbound communication from the team was equally poor. Major decisions and feature releases were not discussed with the most engaged users; they were simply announced on the site, often blindsiding the community.

As criticism mounted, the team seemed to retreat into a bubble, insisting that critics were unfair and “toxic.”

Meanwhile, the value of the crypto token plummeted to 1% of its peak value, leaving early purchasers feeling disillusioned or even cheated. It became clear that, in addition to the problems with the platform, there was not a viable economic case for the token on which it was based.

The very foreseeable result of this was an increasingly disgruntled user base. Many early users became harshly critical, and others left the platform.

The team could have easily avoided angering users by engaging in discussions in the community forum, working with concerned users to refine suggestions, and diverting some resources from the roadmap toward implementing features and fixes that were most in demand.

Cashflow, Spending, and Additional Funding

Less than six months after the beta release, the company ran short of cash. Rather than reaching out to traditional investors, the team once again chose to use alternate funding sources. In this case, the team placed a funding solicitation on a crowdfunding service.

The company did not offer shares. Instead, it offered a “future equity agreement” which guaranteed that investors could cash in their investments at some point in the future when equity shares were offered. In this way, the company avoided much of the scrutiny associated with offering securities.

As part of their funding pitch, the team posted an audited financial report. An examination of this report showed high levels of spending for salaries and office expenses, little cash on hand, and significant debt in the form of loans from the team and a few other individuals. (Note that the company is not located in Silicon Valley, but rather in an area where salaries and other costs should have been much lower.)

The team announced their fundraising effort on the Zyzzy platform, with a link to the crowdfunding page. Almost immediately, tough questions from potential investors and harsh criticisms from unhappy users were posted on the crowdfunding site.

The team’s response to the criticisms was very similar to their response to issues raised in the community forum. Rather than acknowledge problems, they down-played the issues and continued to insist that everything was on track, and they simply needed additional funding to complete the roadmap.

One of the team founders posted an impassioned plea on the Zyzzy platform asking for support, and vilifying the critics.

At this point, it is not clear whether the crowdfunding effort will be successful. The criticisms posted, and the team’s weak responses, make it unlikely that anyone who is not already committed to the platform will invest.

In my opinion, additional funding will not save the company. The team has consistently shown an unwillingness or inability to listen to their users and learn from their beta release, and without any oversight, I do not expect that to change.


Most startups fail, even with ample funding and the advice and oversight of experienced investors.

Bootstrap companies, and companies that use non-traditional funding sources such as ICOs and crowdfunding, have even lower odds of success. Even experienced teams can easily get caught up in their own vision, and shut out opinions that conflict with their dream.

That’s why it’s essential for any company that relies on non-traditional funding to recruit or hire experienced and knowledgeable outside advisors, and to listen to their users.

This article is accurate and true to the best of the author’s knowledge. Content is for informational or entertainment purposes only and does not substitute for personal counsel or professional advice in business, financial, legal, or technical matters.

© 2019 Robert Nicholson


Robert Nicholson (author) from Silicon Valley on December 06, 2019:

It's official. The company in question has just announced that they will cease operations on December 30, 2019.

Sol Cycler from Multiverse Alley on September 28, 2019:

You were very diplomatic and accurate in your assessment here. I can say this, because I know the platform you are referencing.

I hope they learn from this experience, rather than brush off the constructive criticism as toxic like they have been.

They still have a chance to succeed and I hope they do.

That being said, I've deleted all my pre-September content to bring elsewhere(maybe here) and my September content will be deleted after payout.

I'll keep my account there to hodl the tokens in case they increase in value, which would be great.

Related Articles