Introduction
When you're a developer, it's natural to start a project with the technology.
Which stack? Which architecture? Which database? Which API?
These are important questions. But they often come too early.
Before thinking about code, you need to understand what you're trying to build, for whom, and why.
An application can be technically excellent yet solve the wrong problem.
Conversely, a simple solution can have enormous value when it precisely meets a real need.
A good application starts with a problem to understand, not with code to write.
01 — Start with the problem
Before drawing a screen or creating a database, one question must be clear:
What problem are we trying to solve?
A user generally doesn't think in features.
They don't say:
« I need a dynamic form with conditional logic. »
They say instead:
« My sink is clogged. I need to find someone to help me. »
This difference is fundamental.
The product must understand the user's need, rather than asking them to understand how the product works.
02 — Complexity must belong to the system
It's a principle I place a lot of importance on:
Complexity must belong to the system, not to the user.
Let's take a simple example: a person wants to have their phone repaired.
The system may need to know the brand, model, screen condition, battery, or whether the device powers on.
But that doesn't mean you should immediately present ten fields to fill out.
The user can simply write:
« My Samsung fell and the screen no longer turns on. »
The system must then transform this description into useful information.
The user expresses their problem. The system gradually structures the information.
03 — Design the journey before the screens
Another mistake is to start directly with the interface.
We design a welcome screen, a form, a results page, a profile…
But several coherent screens do not guarantee a coherent journey.
I prefer to start with another question:
What should happen between the moment the user expresses their need and the moment their problem is actually solved?
We can then represent the journey simply:
Need → understanding → qualification → matchmaking → choice → intervention → confirmation
Each step must have a reason to exist.
Each requested piece of information must also have a purpose.
04 — The MVP is not an incomplete application
An MVP is not simply a large application from which features are removed.
It's rather:
the smallest version capable of validating an important hypothesis.
This sometimes means accepting not to build everything.
Integrated payment? Later.
Advanced automation? Later.
Complex dashboard? Later.
The initial goal is to build what allows us to verify that the product truly delivers value.
05 — Technology comes next
Once the problem, journey, and scope are defined, technical choices become much simpler.
We can then think about:
- the architecture;
- the data;
- the business rules;
- the automations;
- artificial intelligence;
- scalability.
Technology then becomes what it should be:
a means to build the product correctly, not the product itself.
It is easy to fall in love with a technology.
It is much more important to stay focused on the user's problem.
06 — AI does not replace design
Artificial intelligence today allows rapid generation of code, interfaces, or even architectures.
But producing something quickly does not mean producing the right thing.
An AI can perfectly solve a poorly defined problem.
That is why I consider AI a powerful tool for design and execution, but not a replacement for product thinking.
First, you must know what to build.
Only then can AI help determine how to build it more efficiently.
07 — Designing also means managing uncertainty
In the real world, not all information is always available.
The user may not know the answer.
A situation can evolve.
A professional may need to confirm certain information.
A good system must be able to function despite this uncertainty.
It should not necessarily block the user simply because information is missing.
A well-designed product knows how to move forward even when all information is not yet known.
08 — Code remains essential
All of this obviously does not mean that development is secondary.
Good design without good execution remains a good idea.
Development turns journeys, rules, and product decisions into a real, reliable, and scalable system.
But code must serve a clear intention.
A few hours of design can sometimes prevent several days of unnecessary development.
09 — Building an application is building a system
An application is not just an interface.
Behind every screen there are:
- users;
- data;
- rules;
- decisions;
- states;
Top comments (0)