WordPress

WordPress is a good tool for one specific part of the job: publishing content that someone on the team has to be able to edit without calling anyone. For that it works, it has an ecosystem, and there is no reason to write something custom.

It stops fitting when the site is no longer content. Every business rule solved by chaining plugins adds a dependency that has to be updated, one more query on every visit, and one more surface to break in through. A site with thirty plugins is not a flexible site: it is a site whose behaviour nobody can describe in full.

The work here runs in two directions. On WordPress: cutting what is not needed, moving into code what was being held up by configuration, keeping performance measured on real users, and keeping core, PHP and the plugins up to date by testing upgrades in a separate environment first. And outside WordPress: recognising the point where the process calls for an application and saying so, instead of stacking more extensions.

This very site came from there. It ran on WordPress with a visual page builder, was archived whole before anything was touched, and was rebuilt in Next.js keeping every indexed URL. That is the kind of decision worth making with data: what is published, what links to it, and what it costs to keep it standing one more year.

The decision deserves to be made with data rather than preferences. The data is concrete: which URLs are published, who links to them, how many plugins are active and which have gone years without an update, how long the page takes today and how many hours a month go into keeping all of it upright. With that picture on the table, the comparison stops being WordPress against something else and becomes what actually matters: what each of the two paths costs next year, and which of the two lets the business do what it needs to do afterwards.