WordPress work you can check before you hire me.
Six credits in WordPress core, five plugins, a theme and ten block patterns on wordpress.org, and the source for all of it is public. Start there, not with my adjectives.
The WordPress work you can verify in about five minutes
Most WordPress pages ask you to believe a claim. Here are things you can check without asking me.
My name is in the WordPress core credits six times , across changesets [62854], [62865], [62967], [62968], [62976] and [63007]. Mostly from testing and verifying other people’s patches, plus a regression test that shipped. You can read every one on Trac.
Five plugins, one theme and ten block patterns of mine are published on wordpress.org.
Every premium feature is free in all of them. No locked buttons, no dashboard advertising, no upgrade prompts. The full source is readable before you decide anything, at profiles.wordpress.org/softglaze.
A portfolio screenshot proves a page rendered once. Published source proves how the work is actually written, and it stays checkable long after the screenshot stops loading.
What I build
Custom themes and plugins written against WordPress coding standards, rescues of slow or broken sites, and builds a non-technical team can edit without breaking.
In practice that means:
More than 60 of the 150+ projects I have delivered under my own name since 2019 were WordPress builds.
Why businesses outgrow a theme and a plugin stack
A premium theme is the right answer for a first site. It stops being the right answer at about the point the site starts earning its keep.
The Generic Reality
- Every change needs a plugin, and every plugin needs an update.
- The theme decides the layout, so the brand bends to fit it.
- Page speed drops a little with each new feature.
- An update breaks something and nobody can say which plugin did it.
- Staff avoid the admin because they are afraid of breaking the site.
- The next developer quotes for a rewrite instead of a fix.
The Custom Solution
That is usually the point where a custom build becomes the cheaper option. What you get instead:
- fewer dependencies, so fewer things that can break
- a theme shaped around your content, not the reverse
- an admin your team will actually use
- code in a repository you own, documented as it was written
What makes my WordPress work different
I write against WordPress APIs rather than around them.
That means hooks and filters instead of edited core files, WordPress coding standards instead of house style, and no plugin added where fifty lines in your own theme would do. It is the same discipline that gets patches accepted upstream.
My standing rule, taken directly from core contribution work: never report a result without confirming the code was actually running. It is why my bug reports get accepted, and it is how I handle your project.
What I focus on in every build:
Written against the platform
Hooks, filters and coding standards, so a core update is routine rather than a rescue.
Fewer plugins, deliberately
Every extension is a dependency. If it can be fifty lines in your own theme, it should be.
An admin people will use
The person publishing at 9am is a user too, and usually the one nobody designed for.
Documented as it is built
Written down while I still remember why, so the next developer does not have to guess.
The problems custom WordPress work actually solves
People usually come to me when one or more of these is true:
The build was written against a plugin’s behaviour rather than the platform’s contract, so an update was always going to break it.
Nobody made it slow on purpose. It arrived one plugin at a time.
Content stops being updated, and the site quietly goes stale.
Layout decisions somebody else made two years ago are now deciding how you present yourself.
Nobody knows why anything was done, so every change starts with an investigation.
What you are actually buying
You are not buying a WordPress website.
A custom build is not about making WordPress complicated. It is about making it harder to break.
You are investing in:
- a site that survives a core update without a rescue call
- fewer dependencies, so fewer things that can break
- an admin your team will actually use
- source, credentials, hosting and documentation transferred to you
- no proprietary framework you can only maintain by paying me
- a build the next developer can pick up without a rewrite
- code held to the same standards as my core contributions
- a developer you can reach directly, start to finish
How I approach WordPress work
My WordPress work follows a structured path because a site that has to hold up for years deserves more than a theme install and a plugin stack.
1. Discovery
What the site is for, who edits it, and where the current setup is costing you.
2. Audit
What is installed, what it costs in weight, and what can be removed.
3. Structural planning
Content architecture, admin logic, template structure, and how much genuinely needs to be custom.
4. Development
Theme, templates and any custom plugin, written against WordPress APIs and coding standards.
5. Testing in the real environment
On a staging site you can log into, with your real content, not a demo dataset.
6. Handover
Repository, credentials and documentation to you. Ongoing maintenance is optional and never a condition of the build.
“A strong WordPress build is not just designed and launched. It is structured to hold up over time.”
Who this is best suited for
WordPress development with SoftGlaze is a strong fit for:
- businesses whose site broke on an update and who do not want that again
- teams who need a genuine custom theme or plugin, not another plugin bolted on
- sites that got slow one plugin at a time
- anyone inheriting a build with no documentation
- businesses that want to own their code outright
- anyone who would rather talk to the developer than an account manager
I am one person, so I cannot take unlimited work, and I will say so rather than let you find out halfway through a build.
Why SoftGlaze is a stronger choice
I do not just use WordPress. I contribute to it.
Six core credits, five plugins, a theme and ten block patterns on wordpress.org, every one of them reviewed by people with no reason to be generous about it.
Development happens in Multan, Punjab, Pakistan, by me, at UTC+5.
You talk to the person writing the code, start to finish. No account manager, and no handoff to somebody you have never spoken to.
If your WordPress site is slow, fragile, or something your team is afraid to touch, let’s look at it properly.
Tell me what is broken or what you want built. If it is not a good fit, I will say so quickly and point you somewhere better. You can read my WordPress code before you send the message.