Straight answers, including the ones that cost me work.
Choosing a developer is not trivial. You want to know what you are actually buying, who is doing the work, and what happens when something goes wrong.
This page answers those directly.
I would rather lose a job to a straight answer than win one with a vague answer. Where the honest reply is a limit rather than a strength, it is written as a limit.
What people actually want to know before committing
Most businesses are not shopping for a website. They want to know whether the result will hold up, and whether the person who built it will still be reachable in six months.
The questions below are the ones sitting underneath the questions people usually ask first.
- What exactly am I buying?
- Who is actually doing the work?
- How does the process work?
- What happens when something breaks?
- Will I own what I paid for?
The answers are below, and none of them require a call first.
The Partnership
You are buying a build, and the code that build is made of.
Source, credentials, hosting and documentation are transferred to you at launch. There is no proprietary framework you can only maintain by paying me, and no retainer you cannot leave.
The deliverable matters, but what it costs the next developer matters more. That is the test I build against.
Because with an agency you rarely know who writes the code. Here you always do.
An agency gives you an account manager, a designer, a developer you never meet, and a handover between them where things get lost. That structure exists so the agency can scale. It is not free, and you are the one paying for it.
I am one developer. That has real limits, and one real advantage:
- the person you email is the person who writes the code
- no handover between people who never spoke to each other
- no account layer between you and a decision about your build
- every claim on this site is one you can check yourself
- and I will tell you when something is outside what I do
I write code to be handed over, not merely finished.
Those are different targets, and only one of them survives you leaving. Written to be handed over means:
- documentation produced while I still remember why
- standard technology, with no proprietary lock-in
- fewer dependencies, so fewer things that can break
- code in a repository you own from the first commit
- a build the next developer can pick up without a rewrite
It also means my WordPress and WooCommerce code is public, so you can judge the standard before committing to anything.
You should not, on my word. You should check. That is what the public record is for:
- six credits in WordPress core, with every changeset number listed
- five plugins, a theme and ten block patterns on wordpress.org
- public repositories on GitHub, including complete applications
- every premium feature free in every plugin, with no upgrade prompts
- an about page whose numbers match the numbers used everywhere else
- and a services page that names what I do not do, before you ask
I am not interested in sounding impressive. I am interested in being checkable, which is harder and considerably more useful.
Client Fit
SoftGlaze is a strong fit for businesses that:
- want to own their 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
It is a poor fit if you need a large team on site, a same-week launch of something substantial, or work outside WordPress, WooCommerce, Shopify and custom PHP or React builds.
Both, provided the work is within what I actually do.
Size matters less than fit. A small business with one clear problem is easier to help than a large one that wants six things at once from one person.
Mostly small businesses, in the UK, Europe and Pakistan. The industry matters far less than whether the problem is genuinely a development problem.
If the answer to your problem is marketing or design rather than code, I will say so and point you elsewhere.
Process & Technology
No.
No. WordPress sites, WooCommerce stores, Shopify storefronts in Liquid, and custom applications in PHP, Laravel and React.
Several of those applications are public on GitHub, including a point-of-sale system with double-entry accounting and an Electron desktop tool.
Yes, heavily, and I would rather tell you than have you wonder.
Nothing reaches you until I have watched it run in the actual environment. My standing rule comes from core contribution work: never report a result without confirming the code was actually running.
If you want to know exactly where it was used on your project, ask and I will tell you.
Yes.
PHP and WordPress first, then WooCommerce, Shopify with Liquid, Laravel, React, TypeScript, Electron for desktop tools, MySQL, Docker and Git.
The list is short on purpose. It is what I can still support properly a year after launch, which is a different question from what I could get working this week.
Six stages, the same on every build:
- Discovery
- Strategy
- Design & Structure
- Development
- Refinement
- Handover
Strong work is not improvised. It is sequenced, tested against reality, and documented as it goes.
Yes.
You will know what stage the work is at and why it matters, without having to chase me for it.
I explain what I am doing and what it is for. If something is going to take longer than expected, you hear it from me before you notice it yourself.
Timelines & Execution
Yes.
Yes, and that is often the better starting point. A clear description of what is going wrong beats a specification written to sound technical.
Part of the job is working out the real requirement sitting behind the first request.
It depends on scope, and I will give you a real answer after the discovery conversation rather than a reassuring one before it.
A focused site, a store rescue, a Shopify migration and a custom application are four very different timelines, and quoting them as one number would be dishonest.
What matters more than speed is that the estimate holds. I would rather quote longer and hit it.
Enough to give context and feedback, not so much that you end up running the project yourself.
You are busy running a business. I will ask when a decision is genuinely yours, and get on with it otherwise.
Yes, where it is wanted, and never as a condition of the build.
Some projects end at handover. Others want continued work. Both are fine, and the second is not a subscription you are locked into.
Maintenance is optional. Walking away with your code should always be an option you have.
Honest Limits
Anything outside WordPress, WooCommerce, Shopify and custom PHP or React builds.
I do not do SEO, paid media, social, branding, mobile apps, or design as a standalone service. When a project needs a designer or a copywriter, I bring in specialists I have worked with for years, named, and told to you before the work starts.
Nobody is ever presented as an in-house team member when they are not.
You have the code, the repository and the documentation, so another developer can pick it up.
That is the point of writing it to be handed over. It is also the honest answer to the real risk of hiring one person, and I would rather state it than hope you do not ask.
For anything ongoing I also keep the documentation current rather than writing it once at launch, so the handover is accurate on the day it is needed rather than the day it was written.
Still have questions? Good. Serious decisions usually deserve them.
If something important is not covered here, ask. A straight question gets a straight answer, including when the answer is that I am not the right fit.
Most good working relationships start exactly that way.
That is how I prefer to begin too.
If you want a developer who tells you what the work will actually involve, let’s talk.
Tell me what is broken or what you want built. You can read my code before you send the message.