Top 5 Failures We Met in Software Development

The entrepreneurial journey often involves learning through failure. Over the past eight years, I've had the privilege of meeting more than 200 entrepreneurs and witnessing a lot of projects that touched heights as well as those that didn't reach their intended goals. In my experience, understanding where things can go wrong is just as crucial as knowing what leads to success, especially when starting the development of a digital product. If you're planning to launch a digital product, this article can provide you with invaluable insights to sidestep common pitfalls.

Disclaimer: The cases discussed below are based on real events. I have replaced certain details to ensure anonymity, but each scenario reflects situations I have personally been involved either as an advisor, friend, or supplier.

1. The Solo Logistics Startup

Who: A passionate non-technical founder who wanted to build a complex digital product for the logistics industry. He had no team, he was a one-man show. He decided not to hire a CTO or at least to get a CTO as a service from the software agency. This might work, but just in case you have basic knowledge of product development.

Reason for failure #1: As they didn't have any software product discovery workshop and no technical requirements, the initial version of the product changed radically every 3-4 months which was causing longer timeline and cost.

Reason for failure #2: The contract was prepared by the software company (which normally is not an issue), but it was totally unfavorable to the client. There were many issues, but the biggest one was that it didn't contain who would own the IP (intellectual property) and this was used against the client at the end of collaboration.

Reason for failure #3: The founder had no access to the code, server, App Store/Play Store, and other services. This created struggles for him to switch to another company easily. Also, if at some point the software company supplier disappeared, he could lose all his assets.

How much they lost: ~400k$ and 5 years

Product Development is a very comprehensive process and it doesn't have shortcuts. Respecting all the best practices and applying the best development frameworks wouldn't result in a 100% success guarantee, but it will increase your chances.

2. The Fintech Talent Conundrum

Who: Big company (5M+ Revenue) from the USA. They wanted to build a premium product and allocated a big budget for it.

Reason for failure: They hired the most experienced Product Owner and gave him the task of hiring the best developers. And he literally has done this. The preparation of the development took a while as they wanted everything to be perfect. They started to look for the best developers and hired a team of 10 developers from different companies, different timezones, from different cultures, but with the best skills. The project started very well and it seemed to be an easy process of development. Everything changed when the first issues came up, which is a normal thing for a big project. Some of the issues that happened:

- one of the key developers left

- the experienced developers didn't want to take care of the easy tasks, so everyone was passing the easy tasks to others

- some of the features needed to be changed based on the first early adopters

- there was no trust between developers and their egos were not helping at all to solve small bugs, that became big bugs later on.

As the issues were coming one after another, and the pressure from the founders was put on the Product Owner to see the results ASAP, this pressure was transferred to the developers, and the majority of them quit very fast. At this stage, as developers left, it was very difficult to form up a new team as the Product Owner didn't have enough time to consolidate the documentation and all the other components. They tried to continue the project, but it was too difficult to continue building a premium product in such conditions.

How much they lost: 500k$

I truly believe that better than having the best developers in the world is to have a good team where all the developers have complementary skills and where trust persists. It's hard to handle a bunch of freelancers who don't have any reason to perform on the project and who can leave without any responsibility at almost any time.

3. Overengineering in Logistics

Who: Midsize, established company with a CTO who had tons of experience on his back. He was that guy who was thinking long-term and considering all the technical edge cases before starting to plan anything. He prepared a document of more than 150 pages just for the MVP.

Reason for failure: He was not aware too much about the budget for development. Even though he had a very detailed requirement document, while the development was running, he was adding more and more details to the requirements to be sure everything was covered. The development was planned initially for 12 months, but after 10 months, just 30% of the planned features were implemented. Of course, those 30% were implemented ideally, but nobody was caring about it.

Result: The founders decided to stop the project as it already consumed most of the budget. The app wasn't never released and remained somewhere on the shelves of Github.

How much they lost: 200k€ just for development

Having an experienced CTO, hands-on is very important and helps a lot to boost the development and the quality of the project. However, a CTO must have not just technical skills, but business skills as well, to understand budgeting and how to develop the app within a certain budget. Sometimes they need to adjust the app to fit the budget.

4. Misjudged Technology in a Sports Startup

Who: Startup from France, backed by a VC. The founder was a business-oriented person with no technical background.

Reason for failure: As a non-technical founder, when software agencies are talking about the technology, you ignore that as you a more interested in the cost of implementation and timeline. Here we had the same case. The software company developed the app according to the business requirements and it worked exactly as the founder wanted them. The issue started when after a while, the software company raised the hourly rate and the founder wanted to find another company, but it was very difficult to find another one to continue with the same code base. They were forced to overpay the initial company.

Result: They spent a lot of money on that company until the moment they touched the limits of that technology and a lot of features were difficult to implement or impossible and the app was moving slower and slower. They decided to find another software company to rewrite entirely the app, to have a good foundation for future scaling up.

How much they lost:

- 10+ clients (the app was moving slowly and new features were not developed)

- 1 year of a slower business development

- 150k€ as development costs + 50k€ as loss because of the clients that switched to other tools

I can't deny that the timeline and the cost of the development are the most important in the first phase. However, when you have enough resources, you must think long-term and take into consideration how would your app perform in 5 years with the features you have in your roadmap and support the number of users you estimate to have by that time.

5. Medtech Expansion Missteps

Who: A small company from the UK, that followed all the best practices, hired a good specialized software agency to develop their MVP. A few months later, they launched successfully the product. They still didn't have any paying users, but there was a lot of noise around the app. The founders decided to boost the project.

Reason for failure #1: They decided to hire a CTO and to form an internal development team. Even though I consider hiring a CTO is a good idea at this stage, the hired CTO had many years of development experience, but with no idea of how to build a real medtech custom software. The CTO's lack of experience in building digital products became a critical issue.

Reason for failure #2: The CTO, started to hire developers and form a team of 3 full-time developers. Besides the lack of experience, I don't recommend any startup to hire full-time developers at this stage as this is a significant pressure on your financials and you don't have the stability to be able to support the cost for the long-term, otherwise, it's not worth it at all.

When the new developers came into the team, the CTO was needed to support them and to share the vision and the roadmap of the app. As time passed, the development team started to generate a big cost, and the CTO was involved more and more in pitching the app to raise money for future development. They entered a vicious circle as the CTO had no experience to take fully this role and no time to prepare for it, on the other side the team was generating a high cost and was not productive because of missing the CTO.

How much they lost: 180k€ In case you start the development of a digital product without a CTO it's not an issue and it might work if you have a good software agency as a partner. This happens quite often in the industry.

However, after you have validated the idea and you want to scale up, you need a dedicated technical guy on the team to take care of the development, and the time that you need to use for business development. Hiring developers is very expensive, and even though you have some paying users, I don't recommend doing that until you have a predictable financial revenue so you can support the cost.

Conclusion

Product Development is a very comprehensive and expensive process that requires a balance between budget, quality, and cost. This balance is so difficult to find as finding it might become an art. This is why before starting the development, we recommend to have a Product Discovery Workshop where to find this balance. For more details on how a product discovery shall look like, you can check this article How to Run a Product Discovery Workshop.

I hope that if you find yourself in any of the above situations, you have enough time to change something and to find a solution on how to fix it. Good luck!