How I judge whether a project actually worked, and how you can check it yourself.
A launch date is not an outcome. This page sets out what I am aiming for on a build, and what evidence exists that I hit it, which is a different thing from asking you to take my word.
Proof of work is checkable. Praise is not.
Any studio can describe its standards, explain its process and quote happy clients. None of that can be verified by the person reading it, which is why this site leans on the public record instead.
So this page does not carry testimonials. It sets out the outcomes I hold a project to, and points at the things you can look up without asking me for anything.
That is a deliberate choice, and it costs me the easiest page on any studio site.
What finishing a project should actually mean
Completion is not the standard. It is the minimum.
A build is not finished because it launched. It is finished when the business is easier to understand, the code is readable by whoever comes next, and nothing about it depends on me still being available.
A project has gone well when the business is:
- easier to understand and easier to trust
- clearer in structure, not just tidier
- honest about what it does and does not do
- able to be maintained without me
- still working after the next platform update
What I would rather hear than praise
The useful feedback is not that something looks good. It is that something became measurably less difficult.
- the site finally says what the business does
- the team can edit it without asking
- the update did not break anything
- the enquiries make more sense
- nobody had to call me about it
- the next developer got on with it
That last one is the real test, and it arrives long after the invoice.
Six outcomes I hold a build to
These are the targets I hold a build to, and where each one can be checked.
Nothing on the page that cannot be checked
Every number and credit on this site links to a public record: changeset numbers, plugin pages, repositories. If something cannot be verified, it is written as an opinion or left out.
The structure explains the offer without help
If somebody has to read three pages to work out what the business does, the structure is wrong. Read this site and see whether you knew what I do by the end of the first screen.
The client can maintain it themselves
Admin the actual team can use, documentation written while I still remember why, and no dependency only I understand. Handover is the design constraint rather than an afterthought.
It survives a platform update
Platform APIs and coding standards rather than edited core, so a WordPress release is routine instead of a rescue. It is the same discipline that gets patches accepted upstream.
The code is readable by the next person
The real test of a build is what it costs whoever inherits it. My plugin source is public on wordpress.org precisely so that claim can be judged rather than asserted.
You can leave without losing anything
Source, credentials, hosting and documentation transfer at launch. No proprietary framework you can only maintain by continuing to pay me. Walking away stays an option you hold.
“The measure of a build is not how it looks on launch day. It is what it costs a year later.”
What those six have in common
Every one of them is about what happens after I leave, rather than how the work feels while it is happening.
Taken together they describe:
- clarity over decoration
- maintainability over cleverness
- fewer dependencies
- honest scope
- documentation as you go
- ownership transferred in full
None of that is glamorous, and all of it is what determines whether the money was well spent.
What that is worth commercially
Those outcomes are not abstract. They show up as costs that do not arrive.
- a rebuild you do not have to commission
- a developer you do not have to brief twice
- an update that does not need rescuing
- a team that stops raising tickets
- a handover that takes an afternoon
What working together should be like
I am one developer, so there is no account layer, no handover between people who never spoke, and nobody to hide behind if something goes wrong.
What that should mean in practice:
Clearer
Because the direction and structure are decided before anything is built.
Stronger
Because you are talking to the person writing the code, start to finish.
Told The Truth Early
Because if something is late, wrong, or a bad idea, you hear it from me before you notice it.
Not Oversold
Because I turn down work outside what I do, which costs me jobs and is still the right call.
Left Independent
Because everything transfers at launch and maintenance is never a condition.
“If a client needs me in order to keep using what I built, I did the job badly.”
Different projects, the same standard
A store rescue, a marketing site and a custom application are very different jobs, and I would not pretend the process is identical for each.
What does not change is the standard applied to them, because that is the part worth being consistent about.
That consistency is checkable in the code, which is the point of publishing it.
Why the standard is worth trusting
Not because I describe it well. Because the same discipline shows up somewhere you can inspect without my involvement.
Where that is visible:
- six credits in WordPress core, changesets listed
- five plugins, a theme and ten patterns on wordpress.org
- complete applications public on GitHub
- an extension live on the Chrome Web Store
If you want work judged on what it costs a year later, let’s talk.
Tell me what is broken or what you want built. You can read my code before you send the message, which is rather the point.