When a company decides to invest in a new software project, the most common first reflex is almost always the same: rush toward the visible part. Features, screens, technology stack, release timelines.
That is understandable. Code can be seen, measured, presented to management. The problem is that it arrives too early in the conversation and, when it arrives too early, it brings with it a series of choices made on still shaky foundations.
Where Fragile Software Projects Come From
In most cases, a software project that goes wrong does not go wrong because of the technology chosen. It goes wrong earlier: goals that were never truly clarified, a process read in haste, a scope left vague, expectations that everyone interpreted in their own way.
That is why a serious software project does not start with the question "what do we need to build?". It starts with a more useful one, and often more uncomfortable:
What needs to work better, for whom, and under what real conditions?
The Analysis Phase: Where Project Quality Is Decided
From that question opens a body of work that does not immediately produce something to show — which is precisely why it is often cut or compressed. You observe how the workflow actually works today. You understand who uses what, where precious minutes are lost every day, which data must flow and which exceptions are physiological.
Only then can you say with confidence whether what is needed is new software, a custom component, an integration with existing systems, or a combination of several things.
Skipping this step has a precise cost: building precise answers for a problem that has not yet been properly understood. A solid setup, instead, helps to:
- Define a realistic and shared scope
- Separate the essential from the secondary
- Identify technical and organizational dependencies
- Avoid unnecessary or premature development
- Build a sustainable path over time
Why Overly Rigid Roadmaps Are Often an Illusion
There is a certain pressure, at the start of a project, to want to plan everything immediately. Detailed roadmaps are reassuring. They give the impression of being in control.
The problem is that they are often built before truly understanding the context in which the solution will have to live. And a roadmap built on unverified assumptions quickly becomes an obstacle, not a tool.
First you understand how the real work functions, then planning becomes useful.
Developing in Steps: Effectiveness, Not Bureaucratic Caution
Proceeding through progressive releases is not a cautious or bureaucratic approach. It is simply the most effective way to build software that actually works.
Small, frequent releases allow you to verify early whether initial assumptions hold up against reality, to adjust course without waste and to avoid ending up six months later with a formally complete solution that is far from how people actually work every day.
This way of working does, however, require a mature relationship between those who develop and those who commission. It requires clarity on priorities. It requires the willingness to challenge requests that seem urgent. It requires continuous dialogue, in which the project is treated as something that is built and refined together.
Technical Choices as Consequence, Not as Starting Point
In a well-set-up project, even technical choices take on a different meaning. The stack stops being a matter of preferences or habits. Architecture stops being a theoretical exercise.
Both become the answer to a concrete question: how do we build something that will last, that can be maintained, that integrates with what already exists and that is coherent with this company's actual complexity?
Starting a Project vs Setting It Up Properly
This is the distinction that, over the medium term, makes the greatest difference.
Starting quickly gives the feeling of already being ahead. Setting up properly means taking one step back, but building on solid foundations. And almost always, looking back after a few months, it is the second approach that has saved time, budget and energy — because every decision made in the setup phase is worth far more than a correction made once development is well underway.
At fabricators, this is exactly how we work. We first read the context, then we write the code. Because a good software project is not just a matter of development: it is a matter of reading, of order in decisions and of quality in the dialogue between those who design and those who will use that software every day.
