Build / WordPress Engineering
Custom themes, performance work and structural fixes for sites that have outgrown a page builder and a stack of plugins.
TechSteps does WordPress engineering for sites that have outgrown page builders and stacked plugins. That means custom themes and blocks, replacing plugins whose cost exceeds their value, fixing performance at the query level, and making the site maintainable by someone other than whoever built it. We work in WordPress properly rather than assembling around it.
What this solves
WordPress is excellent at what it was designed for and is frequently pushed well past it. A site starts with a theme, gains a page builder, then accumulates plugins to fill each gap. Every addition is individually reasonable. The total is a site where nobody can predict what a change will affect.
The symptoms are consistent: pages that take seconds to load, an editing experience that intimidates the people meant to use it, updates nobody dares apply, and a growing sense that the site is held together by luck.
The fix is rarely another plugin. It is usually removing several, replacing them with a small amount of purpose-built code, and giving the site a structure that can be reasoned about.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
What is installed, what each item costs, what is actually used, and where the time in a page load is going. Plenty of sites are carrying plugins nobody has used for two years.
Version control, a staging environment and a verified backup, so subsequent changes are reversible. Doing this first is what makes the rest of the work safe.
Removing an unnecessary plugin beats optimizing around it. The largest performance gains in WordPress usually come from doing less rather than caching more.
Where functionality is genuinely needed, a small amount of well-written code frequently replaces a large plugin, with fewer queries and less update risk.
Once the noise is gone the real bottlenecks are visible, and they are often a handful of expensive queries or an uncached remote request on every page load.
Documented custom behavior, a deployment process and an update strategy, so the site does not drift back into the same state.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Caching plugins layered over optimization plugins layered over a builder. Each adds work. The combination is frequently slower than the original problem.
No version control, no review, no way back. The change works until someone else makes a different one and neither knows what the other did.
An AJAX handler or REST endpoint that does not verify permissions is a privilege escalation waiting to be found. This is one of the most common serious WordPress vulnerabilities.
Content and behavior become inseparable from a third-party tool, so migrating away later means rebuilding rather than moving.
The longer the gap, the riskier each update becomes, and the more of the site is running known-vulnerable code. This is how WordPress sites get compromised.
Questions we actually get asked
Usually not. WordPress is a good fit when non-technical people publish regularly. It is a poor fit when the site is really an application with users, permissions and complex state, because you spend your time fighting the model rather than using it. We will tell you honestly which situation you are in.
There is no number, and the count is a poor proxy anyway. One badly written plugin can cost more than twenty small ones. The question is what each one does on every page load: how many queries, how many assets, whether it makes external requests. We measure rather than count.
Very often, yes. Substantial gains are usually available from removing unused plugins, fixing a few expensive queries, correcting caching and stopping assets from loading where they are not needed. We would establish what is achievable before you commit to a rebuild.
Not by choice for new work. Custom blocks give editors a constrained set of components that are hard to misuse and produce predictable markup, which is better for performance, accessibility and long-term maintenance. We do work on existing builder sites where a rebuild is not justified.
We can handle it under a maintenance arrangement, or set up the process and hand it over. Either way there is a staging path, so an update is tested before it reaches production.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.