From 20–25 legacy back offices to a single configurable product

Tecsidel, part of the EYSA Group, builds and operates tolling software. The company carries a historical footprint of 29 countries, and that history left roughly 20–25 legacy back offices in operation.

In practice, every market and every significant customer had received its own copy of the product: a fleet of monoliths with the same functional purpose and no shared foundation.

The old model scaled by multiplication. Every new operation meant one more copy to maintain, evolve and support, and functional knowledge stayed spread across those copies and the people who had built them, with no single source to rely on.

From that starting point, any cross-cutting improvement cost as many times as there were installations, and entering a new operation looked more like a project than a deployment.

Director of Product & R&D · Tecsidel (EYSA Group). My responsibility in this programme is product direction for the new core: what gets unified, what is solved through configuration, what is redesigned and in which order.

Existing installations remain in operation for enterprise customers, so the transformation had to coexist with them rather than replace them at once.

Customers impose different deployment models: some require on-premises, others accept cloud — on the same product.

The programme runs on a small dedicated team — from 6 → 10 people over approximately two years — not on an unlimited rebuild.

And one self-imposed constraint that shapes everything else: no per-customer forks.

Unify through configuration, not through code customisation. The underlying decision was to treat differences between markets and customers as product parameters rather than software variants. The alternative — a shared trunk with per-customer branches — was faster in the short term and reproduced exactly the problem we needed to solve.

A single main repository for the core. That is what makes the previous decision verifiable: if the code lives in one place, a fork stops being a convenient shortcut and becomes a visible exception.

The same product on cloud and on-premises. Instead of two products with two lifecycles, one configurable deployment model: more expensive to design, and it avoids duplicating maintenance for years.

Redesign critical functionality instead of porting it. Where inherited behaviour could only be explained by the history of one specific installation, it was rebuilt from the use case; where it was justified, it was kept.

The programme runs with a dedicated team of 6 → 10 people over approximately two years, working with Engineering and with the teams that know and sustain the current installations.

A large share of the product work has been turning scattered knowledge — spread across product copies and across people — into functional documentation usable as a shared reference to define, build and answer customers.

The model is validated: a configurable core, one shared main repository, cloud or on-premises deployment, and no per-customer forks as a product criterion.

The product's first real deployment was completed in August 2026.

Configurability is a product decision before it is an architecture decision. As long as differences between customers are treated as legitimate exceptions, no engineering team can avoid forks; once they become product parameters, unification stops depending on individual discipline.

What was direct responsibility and what was shared work.

Owned / accountable

Product direction for the new core: scope, configurability criteria and priorities.

Led

The programme’s dedicated product team, 6 → 10 people.

Partnered

Engineering and the operations teams that sustain the current installations.

Contributed

Functional definition of the redesigned critical capabilities.