Throughout my career, I have worked in different types and sizes of startups, from small ventures with three founders, a developer, and a designer who are risking their savings and loans to start (pre-seed), to startups with more than 60 people with seed and series A investment rounds of over 4 million dollars. It is interesting to see how there are mistakes that can be avoided but, for various reasons, are neither avoided nor corrected.

1. Unable to continue due to legal aspects: Validating legal feasibility should be one of the first things any entrepreneur does before embarking on a project. An example of this happened to me a few years ago with three founders who had a good business idea, validated with users, surveys, various types of analysis, market size estimation, SWOT, feasibility, PESTEL, VRIO, Porter’s Five Forces, etc. We had been working for more than six months and had an MVP ready to apply to an accelerator, and just at that moment, the management of the company they worked for (a major technology company, not in apps but in hardware) found out what they were doing in their spare time and notified them that they had to stop because their contracts clearly stipulated that they could not work on any type of technological project, whether their own or for others. They decided to keep their well-paying jobs and abandon their startup.
   
   The problem could have been something else, such as copyright issues, legal limitations in the country where they are located, the incorrect constitution of the company, etc. However, the solution always involves carefully reviewing the points that could cause future problems and avoiding spending time and money on something that is not legal.
   
   
2. Clinging to completed work: One of the main strengths of managers can sometimes work against them. Being highly intelligent and well-prepared people can sometimes make them think that their knowledge alone can substitute for advice from specialists in other areas. They may believe that thinking only in terms of money and opportunity is sufficient and that programmers should work with what they have, even if the legacy system is obsolete or poorly programmed. This happened to me twice with one large startup and one small one. The systems had been built by different programmers without standards or good programming practices. One case involved an obsolete framework, and the other a programming language closer to COBOL and HTML than to Java or React. However, both CEOs insisted on not losing what they already had and not wasting the time and resources invested in creating a new, modern version—more robust, stable, and well-made—despite constant failures and the near impossibility of implementing new functionalities without breaking the existing ones. The outcome was inevitable: the small startup went under when a competitor with a well-built system emerged, and the larger one lasted a few more years until the investors, who had already spent six years waiting for results and being convinced by poor results but good sales presentations, pulled out.
   
   Most startups I have worked for understand that their first product is an MVP, that the product made by freelance programmers or developed in India at scandalously low prices served its purpose at the time for validating the idea, attracting users, and securing investment. However, they need to create a new, well-made system from scratch, using the knowledge they have acquired, ensuring it is built with standards, robustness, security, and speed.
   
   
3. Leaving the wrong person in charge: In a very complex oil project I participated in a long time ago, the most creative person—but not the most knowledgeable in technological matters—took part in a discussion with the client about how the new system should be. This person, whom we’ll call John, presented innovative and exciting ideas during the group discussion without consulting the Project Owner or the Technology Leader first. He simply let his imagination run wild in front of a client enthralled by the ideas of their particular Picasso. From that point on, the client always wanted to talk to John, have John present, and practically wanted him to replace the Project Owner, even though John’s role was Head of Design. The worst part is that they let John make decisions that were a technological suicide due to the complexity of implementing his ideas. Despite all the warnings and recommendations from the developers, John’s ideas prevailed.
   
   The result was nearly two years of development (double the estimated time), double the originally assigned resources, an increase of more than 180% in the initial budget, and a system that, when attempted to be implemented in the plant, was full of errors, incredibly slow, and ultimately never usable.
   
   Members of a development team should function like a football or basketball team. They need to be clear about the plays, there should be consensus on what needs to be done, a clear chain of command, and while everyone’s input should be heard, the consensus of the different members, contributing their visions based on their knowledge, should prevail.