Code development since I was nine years old.
I still remember the first programs written in BASIC, copying them from my Commodore 64 manual. I was there, sitting with my eyes glued to the screen, trying to interpret those mysterious symbols and make sense of those instructions that, once executed, created "magic" seemingly out of nowhere.
Over the years, I have seen and participated in many projects, but only a few have had a truly resounding echo. Conversely, an impressive number of initiatives, often costing enormous sums, remained there, suspended in a limbo of incompleteness.
In some cases, failure was caused by insufficient marketing budgets. In others, by a market that simply wasn't ready for that type of product. But in all failed cases, I always found one common factor: they didn't start by looking at the market.
My piano teacher often repeated a phrase to me that has stayed with me:
"When you teach, all parents are convinced they have a little Mozart at home. But unfortunately, reality is not like this: beyond talent, which in itself is far from guaranteed, even Mozart had to study".
The same logic applies perfectly to product development.
Whoever has an idea is almost always convinced they have created something destined to revolutionize the world. Maybe it's true, but the creator's opinion counts for zero if the market does not share it.
We see this every day, even in sectors far from technology, such as automotive.
Electric cars certainly represent a part of the future of mobility, but this future has not yet fully arrived.
The infrastructure is immature, charging times are still too long, range is not always adequate, and charging stations are often scarce.
The result? The market has spoken clearly: electric cars have sold poorly, and this proves that, regardless of government mandates or political pressure, no technology can spread if the market is not ready to embrace it.
From Vision to Execution: The Right Process
Those who want to launch a web app or a new digital service often start from the end: they write code, design the UI, commission a logo, create a landing page, and dive headfirst into development. It's understandable: anyone with an idea feels the urge to immediately turn it into something tangible.
But this is a mistake.
The truth is that a digital project does not start with code, it doesn't start with choosing a framework, and it doesn't start with design.
A project starts with one fundamental question:
"Does the market actually want what I have in mind?"
If the answer isn't a clear, demonstrable "yes" supported by data, everything else is just noise.
Problem Analysis
The first phase is not about the idea, but about the actual problem the user experiences.
You must ask yourself:
Does this problem actually exist?
How frequent is it?
How painful is it for those experiencing it?
Would people pay to solve it?
If there is no real problem, the idea has no roots.
Competitor Analysis
Every "new" idea already exists in some form.
If it doesn't exist, there is probably no market for it.
If it does exist, you need to understand why it works, why it doesn't work, how it is positioned, which segments it serves, which ones it ignores, where it fails and, above all, where it leaves room.
This point is often experienced with a certain amount of pain by those who have a "brilliant" idea: discovering that someone else has already thought of it. But in reality, it's a stroke of luck.
Because if there are competitors, it means the problem is real, that people are willing to pay, and that there is a market to analyze. And understanding what others are doing is a powerful accelerator: it avoids years of trial and error, false starts, and wasted investments.
It's not about copying.
It's about understanding where added value can be created.
Many startups make a mistake right here: they look at competitors with a mix of snobbery and fear.
They either underestimate them ("our solution is prettier") or overestimate them ("they have too much of an advantage").
The truth is much simpler:
the competitor is an incredibly valuable source of information, not an enemy.
Simply analyze them objectively: strengths, weaknesses, business model, pricing, communication positioning, quality of user experience, churn, real reviews, community, and unresolved pain points.
Those who know how to read between the lines always discover open spaces, opportunities, and forgotten niches where they can carve out a place for themselves.
Defining the Exact Audience
Once the problem has been identified and the competitive ecosystem understood, comes the crucial part: who are we actually serving?
And here, it is not enough to write "everyone" or "SMEs" or "tech users" or "enthusiasts".
Those are not targets: they are generic categories that allow for no strategy.
To build a product, it is necessary to know every detail of the lives of the people you want to reach.
The fundamental question is: "Whose life is actually changed by what I am building?".
And often the answer to this question can be surprising. Many successful products were not born for "the general public," but for a precise niche, whose every difficulty they knew intimately; it is that niche that is often willing to pay more, allowing a project to start strong and scale. Conversely, when a product "speaks to everyone," in 99% of cases, it actually speaks to no one.
The Minimum Solution: the MVP
The minimum solution? Not what you want, but what is actually needed.
This is where the part that scares those who love developing the most comes in: building less.
Fewer features, less complexity, and generally fewer bells and whistles. There is no serious digital project that doesn't go through an MVP (Minimum Viable Product), which is the simplest possible version that allows you to test real market interest. This is where a very common trap occurs: technical pride. Many developers, trapped by perfectionism syndrome, convince themselves that the product must be perfect right at launch, otherwise it won't hold up to comparison. It is a naive mistake because the market does not reward complexity; it rewards the immediate solution. The true goal of the MVP is not to amaze, but to listen. The question is not: "How do I make it perfect?". The question is: "How do I launch it quickly to understand if this is the right direction?".
An MVP must be raw and essential, but it must truly solve the problem; at least in its most basic form. That is where feedback begins, and that is how you understand what is worth developing and what is not. The market is the only judge that counts.
Communication: The Forgotten Piece
Many extraordinary projects die because nobody sees them. Developers are often convinced—myself included, despite my best efforts to resist—that if a product is good, it will sell itself. Without communication there is no traction; without traction there is no growth; without growth there is no future. You need a clear value proposition, a consistent message, a credible online presence, high-quality informative content, a simple UX, and a clear funnel that leads the user from discovery to purchase.
Ultimately, a digital product is not just software; it is an ecosystem, and whoever launches it must consider everything, not just the code.
The only rule that never changes
After 30 years of development, after hundreds of projects created, recreated, refined and polished, launched and led to success, I have come to a drastic but undeniable conclusion: code does not create success, the market does! Because code is the means but not the end; it is mere technical execution of a response to a need that already exists. Everything else is misdirected enthusiasm, and history—the kind I've witnessed since I was programming on my Commodore 64—teaches only one thing: those who know how to listen to the market win, those who ignore it fail!
