3 Must-Know Lessons From Failed Startups

3 Must-Know Lessons From Failed Startups

Long story short: I failed two of my own SaaS startups.

While I don’t go around shouting this information from the rooftops, I have found value in these two experiences: Value that has helped me ensure my clients don’t make the same classic beginner mistakes that I did.

I’ve noticed, in almost every case, each startup owner I meet is about to make—or at least has thought about making—a choice that could kill the UX/UI rollout of their app or platform.

In this story I’ll share the lessons learned and key takeaways that I use to help my clients avoid the same missteps … and launch their products successfully.

Table of contents:

• These are the two companies I tried to launch

• These are the three lessons I learned when they failed

• Fully complete your design phase before moving to development

• Involve the tech team in every stage of design

• Still want more UX/UI changes? Release the app first, then tweak

• Bottom line: Focus on progress, not perfection

These are the two companies I tried to launch

Let’s first take a look at my personal journey and how I got to where I am today. Before I came to my current company, which I’m happy to say is successful, I tried to launch two startups:

  1. Resti A restaurant pre-booking and pre-ordering mobile application
  2. Workus A human resources management platform for design and development agencies (similar in concept to the agency I’m running right now)
Workus and Resti

Screenshots of Workus and Resti startup prototype assets.

These are the three lessons I learned when they failed

1: Fully complete your design phase before moving to development

A couple of years ago, when building my own agency I noticed we were performing a daily HR-related task that could benefit from a tool that would manage employee vacation data. I realized it was a niche idea that could be applied as a solution across other markets so pulled together a small leadership group and set out to build an HR startup.

We wanted to move quickly and had access to a team of developers so we decided to have the developers build rough design mockups of the features related to their various areas of expertise. It took some time, but the mockups were ready by the time we kicked off our development phase.

It had seemed so obvious to us how the features should work as they were pretty straightforward:

  • Add an employee to the database
  • Book a vacation time slot for the employee manually
  • Allow employees to request vacation and or sick days to be approved by management
  • Create a company-wide calendar for anyone to access to see who is and isn’t at work

Sounds like a slam dunk, right? That’s what we thought, too.

And that is when the problems began:

  • Each front end developer was making his own changes/tweaks to their section of the prototype which were not consistent with the overall platform
  • Each person on the team had a slightly different vision of the final UX despite the fact all the features were outlined in the specs file and mockups
  • All of this led to time consuming discussions during the development phase which blocked the process and made us have to redevelop already created features

In the end, did we save time? No. We lost it and the team was unhappy as we were always stuck in redevelopment.

Here are some examples of the design stages you should plan to go through, as you create your prototype, to be sure to properly vet your design before advancing to the development stage:

  • Create a UI-kit for the project
  • Add specs to your Figma project
Create UI Kit

Create a UI-kit for the project, similar to the one above, with a reusable components-based approach that will help support further development.

Figma

Add specs to your Figma project that contain explanations about how it all works.

Detailed design phase

Save money by doing a detailed design phase before your development phase, so you can vet and fix mistakes early on, rather than trying to re-design at a later phase.

Key takeaways:

  1. Do a proper UX/UI design with all the flows outlined and each step and click of the user put “on paper”  into a Figma prototype before you begin the development phase.
  2. Make a fully clickable prototype and go through the flows with different people to be sure you didn’t miss any business scenarios.

2: Involve the tech team in every stage of design

Startups and even established companies often come to me with design mockups that roughly explain their new product concept but that were not created in collaboration with a tech team. This is a mistake because, just as you don’t want developers to create the design, you don’t want design to work in a vacuum with no input from the tech team.

It’s always cheaper to address and refine errors during the initial design process than it is to fix a problem once you’re further into the development phase. Bring in the tech team early on, and collaborate with them every step of the way, to avoid this issue.

When my team and I started to develop the Workus concept, we made a somewhat similar mistake, even though we, technically, were the tech people. We were so excited about our product, we raced through the design phase, not putting on our tech team thinking caps. Instead we thought, “we’re a UX/UI design agency and we know how it all works.”

It would have been smarter had we slowed down and allowed at least some of our team to take on the role of tech experts and properly think through the user experience. By the time the major features were released we’d shifted our focus to scaling the agency itself rather than creating the UX/UI design we should have built from the get-go, and ultimately we did not launch.

It’s great to be enthusiastic about your product or service, but be sure to back it up with a solid design that has been properly vetted by the tech team every step of the way. Here are some of the roles on a typical tech design team:

  • Design tech lead
  • Product manager
  • Development tech lead
  • Designer working on the project

A tech-savvy review by the the tech design team can help you develop and vet whether:

  • The components designed are feasible by any frontend libraries
  • The logic of the user flow has any gaps or possible issues  

Key takeaway:

Bring in the tech team early on, and collaborate with them every step of the way, to avoid costly mistakes like gaps in business logic or developing non-feasible features.

3: Still want more UX/UI changes? Release the app first, then tweak

It’s normal to want a product to function well at launch. In the end, however, it doesn’t have to be perfect. Your users are the only people who can definitively tell you what works, and what doesn’t.

I’ve spoken to dozens of UX/UI design experts in different niches over the past few years and we all agree. Your end users are the best resource. You’ll get to a point where you can’t really improve your product until you have this essential feedback from real people post launch. We can not tell which UX/UI design is the best for your users. Only users can say that. So, why not re-design the app once you’ve launched and have real-world input?

This is why whenever a client wants to keep “testing” more UX/UI approaches or change something along the way before the app or platform is properly launched, I stop the person and tell this story.

At Resti, the restaurant booking and pre-ordering mobile application, the team and I made a mistake that literally buried our startup.

We had designed the app and started the development phase. Once we reached the 30 to 40% development mark, we decided that we didn’t like the dark-colored UI of the app and that it would be better to switch to a lighter colored theme based on new studies on market preferences.

This one decision sent us off on what became a full redesign of the app. Along the way we decided to slightly tweak a couple of features, and it went on from there.

The redesign itself was time consuming, but once we redesigned it we then had to circle back to the development phase and before we knew it, we’d literally changed the entire application.

Old version vs new version

Some screenshot examples of Resti redesigns (old version, left; new version, right).

Here’s a linear recap of how the decision to change the UX/UI design at a late stage of our launch literally spiraled into the failure of my startup:

  1. Designed version 1
  2. Invested in development
  3. Decided we didn’t like it anymore
  4. Redesigned version 2
  5. Invested more $ into development for version 2
  6. Big competitor launched, grabbed market and gained multimillion investments which we could not keep up with

Key takeaway:

Timing is crucial. If you’ve got a solid enough product design, get your app on the market and work out kinks later.

Bottom line: Focus on progress, not perfection

What is the main takeaway from my startup experience? It’s better to launch than die.

Your software is so vulnerable at the very beginning, it’s easy to run your project into the ground, with common mistakes that can be avoided. Here is an ideal course of action as you begin your startup design:

  1. Design the app using your tech designer’s best practices
  2. Get feedback from your target audience via a clickable Figma prototype and do the required iterations
  3. Develop and launch the app
  4. Screencast the behavior of users by using Hotjar or any other similar apps
  5. Interview your real and paying users
  6. Make the required UX/UI adjustments and implement those as a version 2

I help businesses bring their concepts to fruition. If you’re interested in making a proper and cost-saving UX/UI for your startup which will save you money during the development process, send an inquiry through my Upwork profile and we can discuss your needs and best ways to partner and support you to achieve your objectives.

This article was submitted by and expresses the views and opinions of the independent freelancer listed as the author. They do not constitute the views or opinions of Upwork, and Upwork does not explicitly sponsor or endorse any of the views, opinions, tools or services mentioned in this article, all of which are provided as potential options according to the view of the author. Each reader and company should take the time needed to adequately analyze and determine the tools or services that would best fit their specific needs and situations.
This article was submitted by and expresses the views and opinions of the author. They do not constitute the views or opinions of Upwork, and Upwork does not explicitly sponsor or endorse any of the views, opinions, tools or services mentioned in this article, all of which are provided as potential options according to the view of the author. Each reader and company should take the time needed to adequately analyze and determine the tools or services that would best fit their specific needs and situations.
Article Author
Author
3 Must-Know Lessons From Failed Startups
Bohdan H.
Top Rated Plus
Kharkiv, Ukraine
Software design expert
Hire the Author

Read more from Bohdan Huriev