Process
How a project runs here
In four steps, each ending with something that runs. You know in advance what you get, and you are not dependent on me at the end.
1. Audit or scoping — before you commission anything
It starts with the question of cause, not a list of measures. For existing systems that means an audit; for new ones, scoping: which assumption is riskiest, and what is the cheapest way to test it?
Why this is never skipped: in one completed SEO project the cause turned out to be two plugins cancelling each other out.Without that finding, the following 49 hours would have achieved nothing.The output of this step is a document with scope, effort and risks — then you decide.
2. Delivery in stages you can accept individually
Not one big reveal at the end, but stages that each run on their own. You see something real early and can correct course while it is still cheap.
Technical decisions are written down: what the options were, what was chosen, why, and what that choice costs.
3. Going live — the part many leave out
Delivery includes it actually running: deployment pipeline, TLS, backups, uptime monitoring. That is not an add-on but part of the job. Four systems currently run this way under my responsibility.
4. Operations or handover — your call
Afterwards I keep running it, or you take over. For the latter there is documentation with a technical reference for every setting and separate task lists.
A website only its developer understands is a dependency, not a result. That is why a clean handover is explicitly planned for rather than treated as an emergency exit.
Frequently asked
How does a project run here?
In four steps: an audit or scoping exercise with written scope, delivery in stages you can accept individually, going live including deployment and backups, then operations or handover. Each stage ends with something that runs, not with a status report.
What happens before I commission anything?
An audit or a scoping conversation. It ends with a document naming the scope, the estimated effort and the risks. Only then do you decide whether and how much to commission.
How do you record technical decisions?
As short decision notes: what the options were, what was chosen, why, and what that choice costs. It sounds like bureaucracy but saves the later argument about why something is built the way it is — and keeps it traceable if someone else takes over.
What if the plan turns out to be wrong mid-project?
Then I say so. I have made that call against my own work and discarded four months of code because the analysis pointed elsewhere. The same applies to client work: an uncomfortable message early beats an expensive invoice late.