Web development, when the answer is not a template and a plugin stack. This is the general page. The specifics live on four others.
I build sites on WordPress, WooCommerce and Shopify, and applications in PHP, Laravel and React. If you already know which of those you need, the individual pages have the detail. If you do not, start here.
One developer, four things, done properly
Most studios widen the offer until everything is possible. I went the other way and kept it narrow enough to be good at. That is a deliberate trade.
It means I will turn down work outside WordPress, WooCommerce, Shopify and custom PHP or React builds. It also means the work I do take on gets the attention that a wide offer makes impossible.
Clarity
Structure and content organised so the offer is understood without effort.
Checkable
Six core credits, five plugins, a theme and ten block patterns, all public.
Handed over
Source, credentials and documentation transfer to you at launch.
Usability
No account layer between you and the person writing the code.
What I hold every site to
A weak site rarely fails loudly. It loses people quietly, one hesitation at a time, before anybody gets in touch.
Structure first
Content and templates organised so the offer is understood without effort, because deciding structure late is the most expensive mistake available.
Real devices
Tested with your content on real screens and real connections, not a demo dataset on a desktop.
Speed as a feature
Fewer dependencies, less weight. Most performance problems are decided by choices made before any code runs.
Built to hand over
Documentation written while I still remember why, and code the next developer can read.
Survives an update
Platform APIs and coding standards rather than edited core, so a WordPress release is routine.
Room to grow
Where it matters, the build leaves space for the next thing rather than assuming today is final.
What I actually build with
I do not pick technology for effect. I pick it for whether I can still support it a year from now.
“The right stack is not the one that sounds impressive in a meeting. It is the one somebody can still maintain.”
What you can check before you commit
Rather than testimonials, here is the public record. Every item below can be looked up without asking me for anything.
Six credits in WordPress core, each with a changeset number printed in full, so you can read the actual patch rather than take the count on trust.
Five plugins, a theme and ten block patterns published on wordpress.org, with every premium feature free and no upgrade prompts anywhere in them.
A Chrome extension live on the Web Store, and complete applications public on GitHub including a point-of-sale system with double-entry accounting.
How a build actually goes
The process exists to protect the estimate and to make sure the next developer inherits something workable.
1. Discovery
I want to know what the site has to do, who uses it, where the current one is costing you, and what has already been tried. Getting the problem right comes before quoting a solution.
2. Audit and estimate
What is installed, what it weighs, what can be removed. An estimate given before this is a guess, and I would rather find the surprises myself than bill you for them later.
3. Structure and design
Content architecture, templates and admin logic decided together, because a layout that ignores how content is organised creates work for everyone afterwards.
4. Development
Written in version control against platform APIs, with no plugin added where fifty lines in the theme would do.
5. Refinement
Your real content on real devices. Edge cases, error states, and the paths people actually take rather than the happy one.
6. Handover
Repository, credentials, hosting and documentation. Ongoing work is available and never a condition.
Frequently asked, answered honestly
The questions people actually ask before starting, including the ones where the answer is not what you might want.
It depends on scope, and you get a real answer after the discovery conversation rather than a reassuring one before it. A focused site, a store rescue and a custom application are three very different timelines. What matters more than speed is that the estimate holds, and I would rather quote longer and hit it.
Neither extreme. I do not sell a bought theme with your logo on it, and I do not hand-roll what a well-maintained framework already does properly. WordPress, WooCommerce, Shopify, Laravel and React are the foundations; what sits on top is written for your case.
Yes, where it is wanted, and never as a condition of the build. Some projects end at handover and that is fine. Maintenance is optional, because walking away with your code should always be an option you have.
You do, in full, at launch. Source, credentials, hosting and documentation transfer to you. There is no proprietary framework you can only maintain by continuing to pay me, which is a deliberate design decision rather than an accident.
If your site no longer matches the standard of the business behind it, let’s look at it properly.
Tell me what is broken or what you want built. If it falls outside what I do, I will say so and point you somewhere better.