Startup End Down

02/11/2025 << back to Debugging Myself

Building the Roof Before the Foundation

When I started programming, the cost of a Minimum Viable Product (MVP) represented a significant barrier to entry. Operational expenses (hosting, domain, engineering) and marketing costs to create a public image generated a necessary friction that prevented products from overgrowing their capabilities. Today, however, costs have become so democratized that an MVP can achieve massive visibility long before it is minimally viable. This ease has flooded the tech ecosystem with young people eager to claim the title of 'founder' with products that are, too often, precarious promises or unsustainable code.

This current attitude reminds me of my time as a teenage musician, when long before we knew how to play our instruments, we already had a band name, an album cover, and fans among family and friends. In a way, this excess of boldness, which we could frame within the Dunning-Kruger Effect, is the engine that provides the initial momentum. Declaring that you 'play in a band' motivates you to practice every day; launching an app forces you to develop skills. However, creating a Flappy Bird or a shopping list, where the risk of a bug is negligible, is not the same as commercializing a product whose technical irresponsibility carries critical legal liability.

There is a qualitative leap when commercializing software that operates in critical areas such as fiscal, health, or security, because errors do not just cause a bug, but materialize a harm with severe legal and personal consequences. If invoicing software fails to comply with technical regulations (for example, regarding the integrity or unalterability of records), the manufacturer or commercializer faces direct fines for fiscal non-compliance. Similarly, a health app can pose a real risk to people's lives if it fails in calculating medication or communicating treatments. And any product that processes special category data (health or personal data) must comply with the GDPR, where a data breach entails severe sanctions and criminal liability in extreme cases.

Even if initial regulatory requirements are met, precarious software that functioned as an MVP for a limited number of users may be unable to scale as customers and usage grow. Maintenance costs and technical debt grow exponentially, increasing the risk of service unavailability. This instability translates into mercantile risk. Contractual liability can trigger lawsuits if continuous outages cause loss of profit (lucro cesante) for affected client businesses, and, worse still, if the application becomes unviable and simply disappears, the loss of user data represents not only a service breach but a violation of trust.

The real-life case of Hello.app encapsulates this spiral. The startup was built around the image of a young 'founder' with more focus on notoriety than engineering. Lacking a solid and scalable product, the company grew in visibility faster than its code could support. This culminated in investors filing lawsuits alleging fraud and users reporting the loss or leakage of their data. Perhaps with the necessary friction that old costs provided, the founder would have gained time for momentum to advance in parallel with the product’s solidity. But in today's ecosystem, with an excessively lubricated investment and diffusion floor, they slipped and crashed heavily off the track.

Faced with this scenario, I cannot help but have mixed feelings. On the one hand, I applaud the undeniable value of initiative and democratized entrepreneurship. A broad base of individuals or collectives contributing ideas and solutions beyond economic barriers is, without a doubt, the foundation for the future we should aspire to. Decision-making about what is done and how it is done should not rest solely in the hands of a handful of large corporations guided by their year-end accounts. The collaborative culture of Open Source, with individuals contributing to the common good without seeking immediate economic gain, is an ethical and valuable engine for progress.

However, at the other extreme, we find the culture of the founder-influencer, which seeks solutions to boost its image and achieve quick financial gain, without stopping to consider the legal impact or quality generated in the process. The key lies in the midpoint that balances the necessary figure of the visionary leader who seeks opportunities with the engineer who produces quality solutions. This formula for success is not new: it is the mythical duo of Steve Jobs and Steve Wozniak—the combination of boldness and dynamism with creativity and technical excellence—which allowed modern technology companies to leave behind the 'dinosaurs' that preceded them.

The problem we face is not new; it is a historical review. In the 19th century, the Industrial Revolution demanded that economic initiative be compatible with social responsibility, which prevented anyone from starting a business without a minimal ability to guarantee its viability. This led to the birth of figures like limited liability, establishing a baseline of formality and controlled risk. Today, the laxity of the ecosystem is devaluing the title of founder and the idea of a startup at forced march. Both potential customers and engineers or employees are beginning to look suspiciously at this model of entrepreneurship, being pushed, for security, towards the trust provided by established companies.

The solution involves reintroducing that necessary friction and prioritizing value contribution over image. Instead of biting off more than one can chew, the path is no longer the Minimum Viable Product (MVP), but the Minimum Sustainable and Legal Product (PMSP/MLP). This is a product that meets the technical requirements to be maintainable and scalable, that integrates legal compliance (GDPR, fiscal, sectoral) from its design, and which, fundamentally, contributes real and original value. Only then can the audacity of new founders advance with the necessary solidity to avoid crashing heavily off the track.

exit(0);

<< back to Debugging Myself