WEB DEVELOPMENT / MULTILINGUAL PUBLISHING
Editorial products for European logistics
I joined the Trans.info work during a critical team transition and helped keep a large European logistics portal moving while its technology and visual direction changed.
The work grew beyond maintenance into Next.js migration, redesign, new language markets, analytics, advertising and continued development across other Trans.eu properties. The frontend lived alongside WordPress, Elasticsearch and editorial processes, so every change had more than one technical boundary.
This was not a greenfield project. The important skill was recognizing what had to change, what could wait, and what had to remain working for editors, readers, search engines and advertising.
CONTINUITY
Editorial teams, readers, search engines and advertising continue to depend on the platform while engineering changes happen underneath it. Migration work therefore had to preserve publishing and measurement instead of treating the system as a blank-slate product.
MIGRATION
When I joined the project, the migration from Next.js 12 to 14 had already started, but the finish was still far away. In ideal conditions, successive pages and endpoints would have moved from the Pages Router to the App Router step by step. That decision had not been made at the beginning, which increased the cost of organizing the scope later.
Through alignment and shared work, we reduced the migration: some features were temporarily cut so that the foundation could be finished and delivered separately. From a management perspective, this was mismanagement, not proof that incremental migration was impossible. A developer needs room to present a bolder, smaller and reversible option, even when it requires extra adapters, measurement and parallel maintenance.
PERFORMANCE
After the first versions were deployed, we moved image optimization to WordPress and later improved how images passed through Next.js. Caching worked across several layers: WordPress, Elasticsearch and Next.js. Most of the solution was file-based because expanding the stack would have been too costly and was not allowed in that environment.
Only after about two years did some post statuses fail to refresh quickly enough. We added mechanisms for forcing a refresh of specific data. That did not invalidate the cache; it showed that performance needs a designed path back to current state.
AUDIENCE
Some view prototypes were prepared only for a wide screen. I pointed out that mobile was part of the product, especially when traffic from Google Discover could produce surprisingly strong results there. I do not treat this as a statistic for every site; it is a lesson to check the actual audience before treating desktop as the default case.
EXPANSION
Spanish, Italian and French editions required content pipelines, WordPress configuration, frontend routing, analytics and monetization to work together. PolyTrans became part of that publishing infrastructure.
ONGOING WORK
Work continued around WordPress properties, design implementation, analytics and other technology initiatives for Trans.eu. That longer context makes it possible to change individual parts without losing sight of how the publishing system operates as a whole.
Frontend work and migration-scope reduction on a live platform.
Separate changes into boundaries that can be observed, completed and rolled back when necessary.
Image optimization, Next.js passthrough and cached data across several layers.
Language editions connected to publishing, routing and monetization.
Analytics, advertising and attention to mobile behavior in real traffic.
No. The work happened inside an established multilingual publication with active editorial, search and advertising requirements.
PolyTrans supports parts of the multilingual publishing workflow, while the wider Trans.info work also includes frontend, platform, analytics and design responsibilities.
No. The product was already mid-migration from Next.js 12 to 14 when I joined. We later reduced the scope by cutting some features for separate delivery. The lesson concerns migration management: the incremental option needs to be named and considered early.
Content was stored across several layers, mostly file-based. After about two years, some post-status changes were not refreshed quickly enough, so we added a way to force refreshes for specific data.
KNOWLEDGE BASE
LEGACY · SAFE DEVELOPMENT
Learn the order of an old-application takeover: access, startup, behavior, backup, safe change, and only then a rewrite decision.
Read the article →
MAINTENANCE · HOURS PACKAGE
See when an hours package makes sense, how it differs from a project and on-call support, and why a cheap first version is not cheap maintenance.
Read the article →
PROTOTYPE · TESTING THE IDEA
Learn what you can safely build yourself, where risk begins, and when a prototype is already a good enough tool.
Read the article →
PLATFORM MODERNIZATION
We can separate what must remain stable from what should be replaced, then deliver the migration in useful increments.
Discuss a platform