Because you can check the work before you commit to it.
Most studio pages ask you to take a claim on faith. This one is built the other way round. Every number here appears somewhere you can verify it, and the code is public.
I am one developer. That is a limit and an advantage, and this page is about both.
Why SoftGlaze? Because the work should be checkable before you pay for it.
Six credits in WordPress core, five plugins, a theme and ten block patterns on wordpress.org, and public repositories on GitHub including complete applications.
Why SoftGlaze exists
I came to WordPress a skeptic, writing everything from scratch in PHP and Laravel. Then a deadline landed that I could not hit hand-coding. I gave WordPress an honest try and it shipped early. That was seven years ago.
What I kept noticing afterwards was a pattern:
- sites that looked acceptable but nobody in the business could maintain
- builds handed over with no documentation at all
- plugin stacks nobody could untangle two years later
- code the next developer quoted to rewrite rather than repair
- invoices paid while the underlying problem stayed exactly where it was
So I kept the studio deliberately small.
Fewer projects at once, one person who understands the whole build, and no layer of account management between you and the person making decisions about your code.
What makes SoftGlaze different
Plenty of people can build a site. Fewer will show you the code first, and fewer still will tell you what they do not do.
1 Everything here is verifiable
Six core credits with the changeset numbers printed in full. Five plugins, a theme and ten block patterns on wordpress.org. Public repositories on GitHub. None of it requires you to believe me.
- The changesets are listed by number, not summarised.
- The plugins are linked, not described.
- Every premium feature is free, with no upgrade prompts.
- The numbers on the about page are the numbers used everywhere else.
- The services page names what I do not do, before you ask.
2 I write code to be handed over
Documentation written while I still remember why. Standard technology with no proprietary lock-in. Source, credentials and hosting transferred to you at launch.
That standard is not a preference I describe:
- it is visible in the published plugin source
- it is what gets patches accepted upstream
- it is why the bug reports I file get taken seriously
- it is the reason a handover does not need a meeting
- and it is the same discipline on your project
3 I say no early
If what you are asking for is a bad idea, or cheaper to solve another way, I say so before you spend the money. If it falls outside WordPress, WooCommerce, Shopify or custom PHP and React work, I will point you somewhere better.
Turning down work I cannot do properly costs me jobs. It is still the right call, and it is most of the reason the projects I do take go well.
Why clients stay
Trust is rarely won through claims. It is won by being the same person in week twelve as in week one.
Clients stay because there is nobody to hide behind. If something is late or wrong, it is late or wrong because of me, and I am the one who tells you.
In practice that means:
- you are never a small account
- you talk to the person writing the code, start to finish
- everything is built on a staging site you can log into
- every credential and repository is transferred at launch
- if I cannot give a project proper attention, I say so
- and nobody is presented as an in-house team member when they are not
I do not hide behind jargon, and I do not inflate simple things to sound sophisticated. Most of this work is ordinary craft, done carefully.
Why businesses choose SoftGlaze
I ask before quoting
A lot of questions, because surprises later cost more than questions now. If the brief is wrong, better to find that out before the invoice.
I verify before reporting
My standing rule, taken directly from core contribution work: never report a result without confirming the code was actually running.
I build for the next developer
The real test of a build is what it costs whoever inherits it. That is the constraint I design against, and it is the one most builds ignore.
I am open about AI
I use it heavily and I would rather tell you than have you wonder. Nothing reaches you until I have watched it run in the actual environment.
You keep everything
Source, credentials, hosting and documentation are yours. No proprietary framework you can only maintain by paying me.
“The real test of a build is what it costs the next developer.”
What you are actually buying
When you hire SoftGlaze you are not buying a website. You are buying:
- code you own outright
- documentation written as it was built
- a build that survives a platform update
- fewer dependencies, so fewer things that break
- a developer you can reach directly
- an honest answer when something is a bad idea
- the option to leave without losing anything
- a standard you can verify before you commit
That is the real transaction.
The deliverable matters, but what it costs you to maintain matters more.
The standard is simple: the work should hold up.
I do not aim to produce work that is merely acceptable. I aim to produce work that still makes sense a year later, which is the only test that actually matters.
That means:
- the code should read clearly to somebody else
- the documentation should be current, not written once at launch
- the structure should be obvious rather than clever
- the admin should be usable by the people using it daily
- the build should survive the next platform update
- the whole thing should be somebody else’s to maintain if you want it to be
I care about finish, but never at the expense of function.
I care about elegance, but never at the expense of maintainability.
I care about modern tooling, but never at the expense of clarity.
Who this is a strong fit for
SoftGlaze works best with businesses that want the development done properly, and who are willing to be told when something is a bad idea.
A strong fit if you:
- have outgrown a theme and a plugin stack
- want to own your code outright
- care whether the build survives an update
- would rather talk to the developer than an account manager
- value being told no early over being told yes expensively
- are ready to invest in work that holds up rather than work that merely launches
If that sounds like the way you would rather work, we will get along.
The SoftGlaze philosophy
I believe development work should be:
Clear
Because confusion weakens trust.
Useful
Because beauty without utility is fragile.
Persuasive
Because a site should help people move forward, not just look finished.
Structured
Because everything else gets easier when the foundation is coherent.
Modern
Because outdated signals quietly erode confidence.
Human
Because the best work still depends on judgment, and judgment is not automatable.
“Modern tools. Human judgment. Code you can read.”
If you want development you can verify rather than trust, that is what this is.
SoftGlaze is one developer, a public record, and code you own at the end of it.
If you are ready to work that way, tell me what is broken or what you want built.