DEV Community: ArmelDev

A good application doesn't start with code

ArmelDev — Wed, 14 Oct 2026 08:06:42 +0000

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;

A simple application for the user can be complex behind

ArmelDev — Wed, 14 Oct 2026 08:06:30 +0000

Introduction — Visible simplicity often hides great complexity

When an application is well designed, its use often seems obvious.

The user clicks, provides some information and gets a result. They don’t need to understand what happens behind the scenes.

Yet, this apparent simplicity can hide a large amount of logic, rules, and technical decisions.

User-side simplicity is often the result of well‑managed system-side complexity.

1. What the user sees

The user generally sees only a small part of the application.

They see an interface, some buttons, forms, and results. They simply expect to be able to accomplish their goal without having to think about the system’s internal workings.

For example, to find a professional, they can simply describe their problem and submit a request.

For them, the action is simple.

And that is precisely what the user experience should aim to produce: a natural interaction, without unnecessary complexity.

2. What the system must handle

Behind this simple interaction, the system may have a lot of work to do.

It must understand the provided information, determine what is relevant, apply business rules, verify available data, take constraints into account, and produce a coherent response.

In some cases, it must also handle errors, missing information, various request states, or exceptional situations.

The user does not need to know any of this.

But the system, on the other hand, must be capable of handling it.

3. Why shifting complexity to the user is a bad approach

A solution sometimes consists of directly asking the user for all the information the system needs.

This may seem simpler to develop.

But it often results in endless forms, incomprehensible technical choices, and additional steps.

The problem is then shifted to the user.

A user should not have to understand a product’s internal logic to be able to use it.

If the system is complex, it is not the user who should pay the price.

4. Designing complexity to make it invisible

The real challenge is therefore to design this complexity so that it remains mainly behind the interface.

This requires thinking about journeys, business rules, different scenarios, and the information truly needed at each step.

Instead of asking for everything immediately, the system can gradually determine what it needs.

Instead of exposing all possibilities, it can present only those relevant in the context.

Thus, the developer’s job is not only to make a feature work.

It also involves organizing complexity so that the user does not have to endure it.

5. A good product does not eliminate complexity: it handles it

Complexity is part of many digital products. It is rarely possible to eliminate it completely.

The goal is rather to know where it should be placed.

It can be in business rules, architecture, processing, validations, or internal mechanisms.

But it shouldn't unnecessarily appear in every interaction with the user.

A truly simple application is therefore not necessarily a technically simple application.

It is often an application in which the complexity has been thought through enough to become invisible.

And ultimately, it may be one of the developer's essential roles:

transform the system's complexity into simplicity for the user.

When Should You Stop Adding Features?

ArmelDev — Wed, 14 Oct 2026 08:05:49 +0000

Introduction — The temptation to keep adding more

When designing an application, ideas never seem to run out. A new option, an additional dashboard, an automation, an integration… Every idea seems capable of improving the product.

So we add one feature. Then another. And another, until the application becomes harder to understand, use, and maintain.

Yet one question deserves to be asked before every new addition: does this feature genuinely bring value to the user?

1. The trap of a product that tries to do everything

An application can gradually drift away from its original purpose. By trying to meet every possible need, it accumulates options, screens, and rules.

User journeys become longer. Choices multiply. Some features are rarely used, yet they continue to weigh down both the interface and the codebase.

The problem is not having lots of features. It is losing sight of which ones truly matter.

2. A feature does not automatically add value

An interesting idea is not automatically a priority. Before developing it, we need to understand what problem it solves, for whom, and in what situation.

A feature can be technically impressive without being essential to everyday use. Conversely, a small improvement that removes an unnecessary step can transform the user experience.

A product’s value is therefore not measured by the number of options it offers, but by its ability to help users achieve their goals.

3. Prioritizing means making choices

Prioritizing is not simply about ranking a long list of requests. It means deciding what deserves to be built now, what can wait, and what perhaps should never be developed.

For each idea, a few questions can help:

What real need does this feature address?
How often does this need arise?
How does it contribute to the product’s main goal?
What costs will it add in design, development, testing, and maintenance?
Is there a simpler way to achieve the same result?

These questions do not always lead to an immediate answer. However, they force us to justify our choices instead of turning every suggestion into a development task.

4. The MVP brings us back to what matters

A minimum viable product (MVP) is neither a rushed version nor an application designed to frustrate users. It is a focused version that helps determine whether a solution addresses an important need.

Its scope should be small enough to make progress and learn, yet coherent enough to deliver real value.

Adding too many secondary features too early can delay the reality check: do users actually have this problem? Does the solution help them?

Sometimes, it is better to launch a simple user journey, observe how people use it, and improve it based on concrete feedback than to spend months building every possibility we can imagine.

5. Saying no without closing the door to future improvements

Rejecting a feature today does not mean it will never be useful. It simply means it may not be the right decision at this stage of the product.

An idea can be saved for later, tested in the future, or replaced with a simpler approach. Needs evolve, and the product should evolve with them without losing sight of its purpose.

The role of product design is not to anticipate every possibility from the outset. It is also to create a clear enough foundation for future decisions to be made at the right time.

Conclusion — Do less, but do it better

Adding a feature is often visible. Deciding not to add one can require even more thought.

A good product is not one that responds to every request. It is one that understands its priorities and helps users accomplish what matters effectively.

Before asking “What can we add?”, let’s get into the habit of asking: “What problem are we still trying to solve, and is this really the best way to solve it?”

Product quality is built as much through the choices we make as through the features we decide to leave out.

In the Age of AI, Being a Developer Means Knowing What to Build

ArmelDev — Wed, 14 Oct 2026 08:03:03 +0000

Introduction — Code is no longer the only challenge

With artificial intelligence, it is becoming easier to generate code, explore a language we know little about, or get help using a new framework. In just a few exchanges, we can get an initial implementation in a wide range of technologies.

So, if AI can help us code in almost any language, what still makes a developer valuable?

In my view, one question is becoming more important than the choice of technology: have we truly understood the need we are meant to address?

1. Knowing how to code is not enough to build the right product

We can generate working code, create a compelling interface, and connect a database without actually solving the client’s real problem.

A request may be framed as a list of features, while the real need lies elsewhere: saving time, reducing errors, simplifying a process, or gaining a better understanding of the business.

If we move straight from the request to implementation, we risk building exactly what was asked for, but not necessarily what is useful.

2. AI makes code more accessible, not decisions simpler

Programming assistants can explain a language, suggest an architecture, generate tests, or help fix an error. They speed up certain tasks and open up possibilities to more developers.

But producing an answer quickly does not guarantee that it fits the context. The suggested code may overlook a business rule, mishandle an edge case, introduce a vulnerability, or become difficult to maintain.

We therefore need to know how to read, question, test, and validate what we produce. AI can take part in the work; it does not remove the need to understand the result or take responsibility for its quality.

3. The real question comes before the technical choice

When facing a new project, we often instinctively start discussing the language, framework, database, or architecture. These decisions matter, but they should come after a first step: understanding the problem.

Who faces this difficulty? In what situation? How is it handled today? What really needs to change? What constraints must we respect? And how will we know the solution works?

The answers to these questions shape the product’s scope, its priority features, the user experience, and then the technical choices.

The question is no longer just “Which technology will we use?” but “Do we understand the need well enough to choose the right solution?”

4. Skill also means making the right trade-offs

As code production accelerates, our role does not disappear: it shifts further toward understanding, design, and decision-making. We need to distinguish what matters from what is unnecessary, choose an approach suited to the constraints, and anticipate the consequences of our decisions.

The best solution is not always the most complex one, nor the one using the latest technology. It is the one that meets the need in a way that is reliable, understandable, and adaptable enough.

A developer should not only ask whether they can build a feature. They should also ask whether it is necessary, whether it solves the right problem, and whether its cost is justified.

Conclusion — Understand before producing

Artificial intelligence is changing our tools and the way we work. It can help us write code in a variety of languages and explore solutions more quickly. But it does not make understanding the need any less important. On the contrary, it makes that understanding even more decisive.

Because it is possible to produce code faster than ever and be just as quick to get wrong what needed to be built.

So before choosing a technology or asking AI to generate a feature, let’s take the time to ask the essential question: have we properly understood the problem we are trying to solve?

A developer’s value is not limited to the code they write. It is also measured by the relevance of the questions they ask, the decisions they make, and the quality of the solution they help build.