How I turned a bloated WordPress site into an industrial system that tripled quote requests

Introduction

When ProSilicones64 reached out, their website had been accumulating patches for years. It was a WordPress installation with 23 active plugins, four security vulnerabilities (two of them critical), and a 6.2-second load time that made any procurement engineer close the tab before even seeing the catalogue.

The problem wasn't the design. The problem was that they'd built a house on top of a house on top of another house, and now nobody knew what would break when you touched something.

This case study explains how I scrapped everything and built from scratch a system designed specifically for a technical industrial catalogue. Real code, justified decisions, and measurable results.

The Problem

First thing I did was SSH into the server and enable the MySQL query log. I opened a random product page—a silicone profile for railway door sealing—and counted the queries.

45 queries. To display a page with a title, description, three images, and a technical specifications table.

Why so many? Because each plugin was doing its own thing with no coordination. The SEO plugin queried the database. The caching plugin queried to check if there was cache. The translation plugin queried three times per field. The theme queried global options on every load. And so on, up to 45.

TTFB (Time To First Byte) was sitting at 890ms. That means the server took nearly a second just to start sending data, before the browser could even begin rendering.

• 23 active plugins with no dependency control
• Page load time: 6.2 seconds
• TTFB: 890ms (nearly a second just to start)
• 45 MySQL queries per product page
• 4 active vulnerabilities, 2 critical
• Static catalogue impossible to scale
• No Schema.org markup whatsoever

For an industrial company where procurement engineers have 15 tabs open comparing suppliers, that's commercial suicide.

The decision: scrap everything and rebuild from scratch

There were two options. First: optimise what existed—disable plugins, install aggressive caching, hope nothing breaks. Second: migrate to a bespoke system designed specifically for what ProSilicones64 actually needed.

I chose the second. ProSilicones64 isn't an e-commerce store or a corporate blog. It's an industrial manufacturer with a complex technical catalogue: 30 products, 19 silicone compound series with different properties, 10 industrial sectors, 127 standards and certifications. Each product can be manufactured in multiple series, each series has specific temperature and hardness ranges, each sector requires specific certifications.

WordPress wasn't built for this. You can force it with custom fields plugins and custom taxonomies, but you end up with a monster that nobody understands and that breaks every time you update something.

The architecture: straight PHP, relational MySQL, zero unnecessary dependencies

I didn't use Laravel or Symfony. Not because they're bad—they're excellent frameworks—but because for this project they added complexity without real benefit. ProSilicones64 doesn't need an ORM abstracting the database; it needs optimised SQL queries that return exactly what each page needs to display.

Each controller does exactly one thing. The product page controller calls the product service, which calls the repository, which executes a single SQL query with the necessary JOINs. One request, one query, one response.

The results: real numbers, not projections

After three months with the new system in production, here's the comparative data. The last number is the one that matters: from 8 monthly quote requests to 31. Not because the design looks better—it's virtually identical—but because the site loads fast, products are easy to find, and the contact form works without JavaScript errors.

Conclusion

This project confirmed something I already suspected: for industrial companies with technical catalogues, WordPress is the wrong choice. Not because it's bad, but because it was designed for a different type of content.

A personal blog, a five-page corporate site, a standard online shop... WordPress handles those perfectly well. But when you have complex relationships between products, series, sectors, and regulatory standards, you need a database that reflects that complexity. And when you need real speed to compete with other manufacturers, you need full control over every query that runs.

ProSilicones64 now has a website that can scale without degrading. Adding a new silicone series means inserting rows in the database, not installing another plugin. Adding a new sector means creating relationships, not hacking shortcodes.

And when they want to redesign the front-end five years from now, they'll be able to do it without touching the business logic. Because they're separated. Because that's how you build systems that last.