I did not return to MODX to build websites on MODX again.

I returned because today there is a vast layer of old projects that still make money for businesses, but have themselves become a technical constraint. And for such projects, someone who simply knows how to install pdoTools, edit a chunk, or update miniShop is not enough.

You need someone who understands both old MODX from the inside and where the project needs to move next.

That is precisely my case.

I did not just use MODX

I came to MODX a long time ago and rather quickly ran up against the architectural limitations of the system itself, rather than a lack of ready-made components.

When there weren't proper administrative tools for executing code and inspecting a live runtime, Console appeared.

When it became clear that working with data was too tightly bound to the frontend/runtime and snippets, modxSite appeared—an API-first layer built on processors and xPDO.

When storing template code in the database started getting in the way of portability and proper development, phpTemplates appeared first, followed by modxSmarty.

When an ecommerce model was needed without turning the project into yet another thick framework on top of MODX, shopModx appeared.

In other words, these were not random Extras. They formed a single lineage:

less magic → more explicit API → proper models → processors → file-based code → separation of presentation

Some of the old code and examples are still publicly available:

• shopModx
• modxSmarty

I poked around not just components, but the core itself

One of the key traits of my work with MODX is that I stopped treating the platform's boundaries as something sacred quite early on.

If the standard mechanism couldn't handle a task, I would dive into xPDO, the request lifecycle, the cache map, routing, and internal MODX classes to see where the actual limit lay.

For example, when dealing with hundreds of thousands of resources, the problem wasn't some single slow snippet. MODX would attempt to build and cache a massive resource map in its entirety. For projects with 150,000 documents, I had to rewrite parts of the request mechanism because the standard model was already falling apart.

In a discussion about a project with 500,000 resources, I wrote explicitly: without serious tuning, out-of-the-box MODX comfortably handles roughly tens of thousands of resources; beyond that, you have to change the approach itself.

This is a good example of the difference between "knowing MODX components" and understanding where and why the architecture itself stops bearing the load.

I argued with the dominant approach not out of a love for argument

In the Russian-speaking ecosystem, a different path won: more ready-made universal components, a lower barrier to entry, and faster website assembly by integrators.

I argued with this approach for many years because I looked at MODX as a programmer.

I was interested in:

• data models;
• APIs;
• code portability;
• inheritance;
• processors;
• separation of concerns;
• maintenance costs over the years.

Hence modxSite, modxSmarty, and shopModx.

Today, the argument is no longer particularly interesting. What is more interesting is this: time has provided an opportunity to test architectural decisions over the long haul.

Right now, it is precisely the coupling of old MODX projects with the runtime, Extras, and the presentation layer that has become one of the main problems during modernization and headless transitions.

Then I went far beyond MODX

For the past 10+ years, I haven't been sitting inside this ecosystem.

I've worked with modern backend and frontend stacks, APIs, Node.js, React, GraphQL, infrastructure, and large engineering systems. I worked my way up to bigtech and a tech lead position.

This matters more than any line reading "N years of experience with MODX."

Because today, the challenge facing the owner of an old MODX site is not to find the most experienced person for chunks.

The challenge is to guide a working legacy project across the technological frontier:

old MODX → API → new frontend → new services → gradual decommissioning of legacy

Knowing only the old side is not enough for this. And knowing only the new side is not enough either.

Why this matters today

A modern developer might know Next.js, GraphQL, Kubernetes, and AI integrations inside out, yet open a 2013 MODX project and understand absolutely nothing.

An old MODX specialist might know TVs, Fenom, pdoTools, and miniShop brilliantly, but lack any experience in designing systems outside that ecosystem.

My value lies at the intersection: deep knowledge of legacy MODX + experience with architectural work within it + 10+ years of modern development outside MODX + technical leadership experience.

This is precisely why I can take on not just a separate tweak, but technical responsibility for transitioning a project from one generation of technology to another.

What I am not going to do

I am not going back to the cheap MODX website assembly market.

I am not offering to build new projects on MODX.

And I am not going to convince an owner who is entirely happy with their current stack that they urgently need a migration.

My audience consists of those who are already feeling the pain:

• the website makes money, but developing it is getting harder and harder;
• old contractors are disappearing;
• new specialists are afraid to touch the legacy code;
• a complete rewrite is too risky;
• the business does not want to depend on MODX for another ten years.

---

I know both sides well enough not to force the business to choose between eternal legacy and a dangerous rewrite from scratch.

That is precisely the point of my return to MODX today.