The website after the theme

Putting a website online is not enough. We must understand what we are asking it to become.

For many years, the digital market has made an almost invisible mistake, precisely because it has been repeated so many times: it has confused the website with the tool used to build it.

“It is a WordPress website.”
“It was made with Elementor.”
“It is based on a premium theme.”
“It was developed with this or that framework.”

As if the client should really care about the hardware hidden behind the wall. As if identity, reputation, function, speed, readability, accessibility and the long-term value of a digital project could be reduced to the name of the platform on which it happens to rest.

We believe it is time to step out of this confusion.

A website is not WordPress. It is not a theme. It is not a builder. It is not a stack of plugins. Strictly speaking, it is not even a technology. A website is a public form of presence. It is an interface between an organisation and the world. It is a device for communication, relation, reputation, sales, orientation and service. It may be simple or complex, static or dynamic, editorial or functional, institutional or operational. But before it is developed, it must be thought through.

The technology comes later.

Or at least it should.

WordPress is not the problem

The problem today is not WordPress. It would be too easy, and intellectually rather dishonest, to turn it into the scapegoat. WordPress has played a fundamental role in the history of the contemporary web. It has democratised online publishing. It has given a voice to companies, professionals, publishers, associations and individuals. It has allowed millions of organisations to go online without having to depend on expensive, closed or barely governable architectures.

This has been its great strength: a democratic nature that is both real and apparent. Apparent, because ease of access never automatically coincides with quality of outcome. Real, because WordPress lowered a threshold that had previously been much higher, allowing a vast part of the web to be born, to grow and to experiment.

Every democratisation, however, carries an ambiguity.

When a tool becomes accessible to many, many begin to use it without fully understanding the consequences. WordPress, precisely because of its enormous spread, has allowed an entire generation of hybrid figures to “make websites” without necessarily understanding information architecture, semantic HTML, performance, security, accessibility, technical SEO, user experience design, code maintenance, data responsibility and long-term technical sustainability.

This is not WordPress’s fault. It is the fault of the market that has grown around it.

A huge market, lively, creative, often useful, but also full of shortcuts. Themes, builders, plugins, add-ons, extensions, packages, optimisers, compressors, corrective caches, tools designed to repair problems produced by other tools. An economy of accumulation, where every difficulty is often solved by adding something else.

A plugin to do what the theme does not do.
An add-on to correct the builder.
An extension to compensate for a limitation.
A cache system to hide accumulated weight.
An optimisation layer to compress something that perhaps should never have existed in the first place.

Little by little, the website stops being designed. It is negotiated, piece by piece, with the limits of the theme, the builder and the plugins installed.

The unconscious use of WordPress

The unconscious use of WordPress does not begin with using WordPress. It begins with believing that WordPress is enough. With thinking that installing is the same as designing. With confusing the availability of a function with its relevance. With buying a theme and believing one has bought an identity. With filling a backend with plugins without asking who will maintain them, update them, pay for them, understand them, defend them and fix them when they inevitably begin to conflict.

Ease of access does not coincide with project maturity. Publishing a page does not mean building a system. Installing a plugin does not mean solving a problem. Buying a theme does not mean creating a presence.

In the end, the cost of this unconsciousness is almost never paid by those who produce it.

Clients pay for it, with heavy websites, opaque maintenance, recurring licences, technical dependencies, risky updates, vulnerabilities, poor performance and continuous redesigns.

Companies pay for it, believing they have bought a tool and discovering instead that they are living inside an unstable technical condominium, where every tenant consumes resources, demands updates, argues with the others and occasionally breaks the lift.

Users pay for it, with slow pages, confused interfaces, unstable layouts, unnecessary scripts, tiring experiences and content buried under layers of effects and automatisms.

The web itself pays for it, becoming heavier, less readable and less essential.

And even WordPress pays for it, because it is often judged not for what it is, but for the abuses committed in its name.

Our position is therefore not against WordPress. On the contrary, it may be a more respectful position towards WordPress itself.

We want to bring it back to its best role.

WordPress as a CMS.
WordPress as an editorial system.
WordPress as an ordered archive of content.
WordPress as a publishing engine.
WordPress as a system for managing roles, revisions, taxonomies, media, translations, publishing flows and structured content.

Not necessarily WordPress as a façade.
Not necessarily WordPress as a theme.
Not necessarily WordPress as a total environment.
Not necessarily WordPress as a graphic destiny.

This distinction matters.

Using WordPress to govern content is one thing. Allowing a theme, a builder or a combination of plugins to determine the final user experience is another. Having a solid, familiar and extensible backend is one thing. Delivering to the public an overloaded page generated by layers of code designed to do everything, including what that specific project does not need, is something else entirely.

Beyond the theme

We are choosing a different path.

When appropriate, WordPress can live behind the scenes, on a technical domain or on a third-level domain, as an editorial and management engine. The public frontend can instead be built with clean HTML, controlled CSS, JavaScript only when necessary, clear semantic structure, native accessibility, server-side caching and performance designed from the beginning.

But this is only one of the possibilities.

Sometimes the best answer will be a static website, simple, fast, almost mineral in its essentiality. Sometimes it will be WordPress as a headless CMS. Sometimes it will be WordPress in its traditional form, because it is sufficient, proportionate and correct for the need. Sometimes it will be Laravel, when a more structured application is required, with specific logic, management panels, roles, processes and functions that go beyond ordinary content publishing.

Sometimes it will be PostgreSQL instead of MariaDB or MySQL, because the data model, the relations, the queries, the reliability and the future growth of the project require it. Sometimes it will be MongoDB, if the nature of the data is less rigid, more document-based, more fluid. Sometimes it will be Python, if automation, analysis, artificial intelligence, processing, integrations or asynchronous workflows are needed. Sometimes it will be Go, if lightness, concurrency, robust services and solid performance are required. Sometimes it will be Next.js or another modern framework, when user experience, scalability, interactivity or frontend distribution make it appropriate.

This is not about chasing the technological fashion of the moment. That would merely be another form of unconsciousness.

It is about recognising that different problems require different tools. And that the abundance of WordPress, precisely because it is enormous, convenient and apparently sufficient for everything, has often narrowed the technical imagination of the market.

For years, many questions have been automatically translated into the same answer: “we will do it in WordPress”. Institutional website? WordPress. Portal? WordPress. Catalogue? WordPress. Restricted area? WordPress. Editorial system? WordPress. Management application? WordPress. Internal workflow? WordPress. Custom function? Plugin. Integration? Plugin. Performance? Plugin. Security? Plugin. Cache? Plugin. Translations? Plugin.

By always having an answer available, the market has often stopped formulating the question properly.

This may be the most subtle consequence of the WordPress monoculture: not only heavier websites, not only technical dependencies, not only more fragile maintenance, but a progressive reduction of the field of possibility. Entire families of technologies, languages, databases, frameworks, architectures and opportunities have been excluded not because they were unsuitable, but because they were outside the dominant habit.

And yet, very often, they work better.

They work better when there is a good project at the base. They work better when the problem has been understood before choosing the tool. They work better when data is modelled with care, when functions are designed, when the experience is shaped, when maintenance is foreseen, when the architecture does not arise from the convenience of the moment but from the real nature of the system to be built.

Technology alone saves nothing. Laravel used badly can become as heavy as a mistreated WordPress installation. Python used without discipline can produce disorder. Next.js can turn into an exercise in technical vanity. MongoDB can be chosen by fashion rather than by necessity. Go can be excessive where something simpler would suffice.

The difference is not made by the name of the stack.

The difference is made by the quality of the project.

The end of the single technical horizon

For this reason, we no longer want to limit ourselves to the PHP world, nor to the mental enclosure that has often been created around WordPress. PHP remains a useful, mature, widespread and effective tool when used well. WordPress remains an important ecosystem. But they cannot be the only horizon.

A mature digital project must be able to choose.

It must be able to choose the language, the database, the framework, the frontend, the backend, the degree of static or dynamic behaviour, the level of automation, the type of hosting, the cache strategy, the APIs, the integrations and the services. It must be able to decide when to use ready-made tools and when to build. When to rely on a CMS and when to avoid one. When to use a relational database and when to use a document-based one. When to serve pure HTML and when to generate more complex interfaces. When to remain simple and when to accept necessary complexity.

The question is no longer “WordPress yes or WordPress no”.

The question is: what architecture does the project really need?

This is not about headless fashion. It is not about chasing yet another technical label. It is about separating responsibilities.

The CMS manages content.
The frontend manages the experience.
The server manages what the server can do better.
Custom code solves what is truly specific.
Plugins enter only when they bring real value, not when they are needed to cover a lack of design.

This is the logic we internally call theme-less.

Without a theme does not mean without identity.
Without a builder does not mean without freedom.
Without unnecessary plugins does not mean without functionality.

On the contrary, it means building a digital project without starting from a prefabricated cage. It means refusing to let a universal theme decide in advance the form, weight, logic and limits of a website. It means not turning every client request into a technical compromise with tools designed to work generically for everyone and perfectly for no one.

A theme always carries a worldview with it. Grids, components, animations, scripts, dependencies, styles, shortcuts, behaviours. At first it seems to accelerate the work. Then, often, it begins to charge a toll. The project adapts to the theme, not the theme to the project. CSS is forced. Corrective code is added. A plugin is installed. An exception is created. Something heavy is then optimised. Performance is pursued instead of being planned.

The best optimisation, however, is not compressing unnecessary weight.

It is not generating it.

Lightness is not poverty

For us, this is not a technical nuance. It is a project posture.

A light website is not born at the end, with a performance checklist. It is born at the beginning, when one decides what not to install, what not to load, what not to delegate to disproportionate tools. It is born when one distinguishes between necessary function and market habit. It is born when one understands that every component has a cost: in speed, security, maintenance, readability, dependency and risk.

Lightness is not poverty. It is precision.

An essential website is not a poor website. It is a website that refuses to be weighed down by what is not needed. It can be sophisticated, elegant, articulated, dynamic, editorial, integrated with external systems, connected to APIs, powered by a CMS, linked to CRMs, automations, analysis tools and intelligent functions. But every element must have a reason. Every choice must have a responsibility. Every technology must deserve its place.

The economic relationship with the client also changes.

Fewer premium themes.
Fewer builders.
Fewer add-ons.
Fewer compensation plugins.
Fewer unnecessary recurring licences.
Fewer conflicts.
Fewer critical updates.
Less passive maintenance.
Less dependence on opaque ecosystems.

This does not mean spending less because the work is poorer. It means spending better because the work is more conscious.

A website should not become a hidden annuity of complexity. It should not force the client to pay indefinitely to keep alive a pile of tools that often exist only because someone, at the beginning, did not really want to design. Maintenance is necessary, of course. Security is necessary. Evolution is necessary. But unnecessary complexity is not maintenance: it is technical debt transformed into commercial habit.

From the need, not from the tool

We prefer another idea.

Start from the need, not from the tool.

Understand what the website or system must do. Who must update it. How often. With what content. In which languages. With what data. With what flows. With what responsibilities. With what level of autonomy. With what objectives of reputation, sales, service, relation or automation.

Only then should the architecture be decided.

Sometimes the answer will be pure HTML.
Sometimes it will be WordPress, used well and without overload.
Sometimes it will be WordPress as a headless CMS.
Sometimes it will be Laravel.
Sometimes it will be Python.
Sometimes it will be Go.
Sometimes it will be Next.js.
Sometimes it will be PostgreSQL.
Sometimes it will be MariaDB or MySQL.
Sometimes it will be MongoDB.
Sometimes it will be an API.
Sometimes it will be a custom function.
Sometimes it will be a light service that does one thing, but does it well.
Sometimes it will be a more articulated system, because the need requires it.
Sometimes the most intelligent solution will be to remove, not to add.

The technical choice must be a consequence of the project, not its enclosure.

For us, this changes everything.

Building websites often means assembling tools that already exist. Designing digital presences and systems means understanding which technical form a real need must assume. It means bringing together communication, architecture, content, interface, data, performance, maintenance, security and responsibility. It means not stopping at the surface and not being seduced by the easy promise that “there is a plugin for that”.

Of course, almost everything “can be done with a plugin”.

The question is different: does it make sense?

Does it make sense for the client? Does it make sense for the user? Does it make sense for security? Does it make sense for maintenance? Will it still make sense in three years? Does it make sense compared with the value produced? Does it make sense compared with the simplicity that would otherwise be possible? Does it make sense compared with alternative technologies that could do better, with less weight, fewer dependencies and more control?

More consciousness, less accumulation

The future of the web will not necessarily be more complex. For those who want to work well, it will be more selective.

Less technical monoculture, more architecture.
Fewer accumulated tools, more project responsibility.
Fewer websites built around a theme, more systems built around a need.
Less technical unconsciousness, more digital consciousness.

WordPress will continue to be an important tool. Precisely for this reason, it must be used with more respect, not less. It must be freed from the idea that it can do everything in the same way, for everyone, always. It must be brought back to its original strength: managing content, making publication accessible, offering a solid core on which to build when it makes sense.

The rest must be designed.

And designing also means having the courage to leave the enclosure when the enclosure is no longer enough.

A website, a portal, an application, an archive, an editorial system or a service platform should not be the random sum of what one ecosystem makes available. It should be the clearest, lightest and most responsible form of what an organisation wants to say, do and make possible.

This is where we want to start again.

Not from the theme.
Not from the builder.
Not from the plugin.
Not from the platform as a fetish.
Not from a single technical language.
Not from a single ecosystem.

From the need.
From the architecture.
From the content.
From the experience.
From the data.
From the function.
From responsibility.

The web does not need more plugins.

It needs more consciousness.