Technology
Why our technical choices commit for the long run
A custom business application is not an ephemeral product. It is built to live for years — often ten, sometimes more. The technologies it rests on are therefore chosen on that same horizon, not on the horizon of a trend cycle. That horizon shapes most of our technical decisions.
A choice of language, framework or platform is made at the start of a project. It becomes very costly to revisit afterwards. Migrating an application from one stack to another sometimes costs more than rebuilding it — and exposes you along the way to functional regressions no client is willing to absorb. What we therefore assess at the start of a project is not only what works today, but what will still work in ten years.
This horizon frames our technical choices. It translates into two principles: openness and longevity.
Open source as a position of principle
Most of the technologies we work with are open source. The choice is not ideological. It answers concrete criteria that matter over the lifetime of a business application.
Independence first. An application built on technologies whose licence is held by a single vendor ties you to that vendor — to its pricing policy, its strategic choices, its changes of direction. Open source breaks that bond: the code can be maintained, taken over, audited, extended, without dependence on any single actor.
Transparency next. When the code of a component is open, you can know how it works, fix it, secure it without waiting for a patch to come from elsewhere. This transparency passes on to your team, who can build expertise on what makes their applications run.
The ecosystem finally. The open source technologies that have established themselves have active communities, abundant documentation, and many available profiles on the job market. Recruiting, training, evolving an application is easier on a mainstream stack than on a niche one.
We don't rule out proprietary software — it has its place when it brings functional value that no open alternative reasonably covers. But open source remains our default choice, because it preserves the freedom of action you are buying with a custom application.
Our technical families
Our technical scope covers the main families that structure a modern business application.
On the backend, we work with the established server-side languages — PHP, Python, server-side JavaScript — and their major application frameworks. The choice is made project by project: expected volume, profile of the client team, existing ecosystem. No language is universally better — each is better for certain classes of problems.
On the frontend, JavaScript and its dominant frameworks shape our interfaces. The choices range from server-rendered applications — sober, robust, accessible — to rich client-side interfaces when the user need justifies it. The criterion is never the most recent technology: it is the experience your users will have, on first use as on the thousandth.
On the CMS side, our long-standing expertise with Joomla has given us a fine-grained understanding of what a professional content management system is. That base extends to the main open source ecosystems as the editorial and functional needs of the project require.
On hosting, we favour sovereign infrastructures and European-based providers, which secure data residency and regulatory predictability. The choice between dedicated server, shared infrastructure and containerisation is made according to expected load and the operational profile of your team.
This palette doesn't aim for exhaustiveness — it reflects an engineering practice choice: few tools, mastered in depth.
What makes a stack last ten years
The ten-year horizon of a business application is not an abstract argument. It translates into concrete criteria, which guide every technical choice at the start.
Maturity first. We favour technologies that have proved themselves over several cycles, whose major versions follow one another without breaking backward compatibility, whose bugs and vulnerabilities are known and handled. A recent technology may be brilliant — it remains a bet until time has demonstrated its stability.
Community activity next. A stack sustained by a large and engaged community keeps evolving, getting more secure, expanding. When that community shrinks — maintainers leaving, declining usage, enterprises pulling out — a countdown starts on the applications that depend on it.
Governance finally. A technology carried by a recognised foundation, by a consortium of major actors or by an independent community offers continuity guarantees that exceed those of a technology resting on the goodwill of a single vendor.
These criteria also apply to applications inherited from the past. When a project requires taking over existing code — modernising a platform, migrating an obsolescent stack, integrating a legacy component — the same assessment framework guides the decision to modernise, rewrite, or extend.
Where this leads
The technologies we work with are only worth what the applications they serve are worth. The things we build — portals, platforms, internal tools — are detailed on the Custom business applications page. The way we scope a project to secure the solidity of the result is covered on the Our approach page. And to see these technical choices at work in finished projects, our selected work offers a tangible sample.