How I work
One developer, one method, everything in writing. This page is the operating manual — the same one every client here works under, published so you can judge the process before you buy it.
1 · Brief before price
Every engagement starts with a written brief — yours or mine, either works. The brief answers the six questions that determine every number: goal, scope, constraints, content responsibility, timeline, budget band. From it comes a written scope with milestones and a fixed or banded price. Not a fit? You keep the scope document; it works with any developer, and that is deliberate — a scope that only works with me is not a scope, it is a lock-in.
2 · Scope as contract, not vibes
The scope becomes the statement of work: deliverables page by page, integrations named, content responsibility explicit, milestones with acceptance criteria. Ambiguity is the enemy of both sides — every “I assumed” in a project was a sentence missing from this document. Changes after signing go through a one-paragraph change note: what changes, what it costs, what it moves. No surprise invoices, no surprise scope.
3 · Weekly demo, not status reports
Once a week you get a staging link with what changed and a two-minute note on what is next. Working software is the only honest status report — “90% done” means nothing, a link you can click means everything. Between demos, async updates as things land. You are never more than a few days from seeing the actual state of the actual build.
4 · Staging always on
From the first week, your project lives on a staging URL you can open any time. Watch it evolve, share it with your team, form opinions early. The alternative — a big reveal at the end — is how projects end up rebuilt instead of revised. Early feedback is cheap; launch-week feedback is not.
5 · Launch as rehearsal, not event
Launch runs off a checklist, not adrenaline: final QA on production hardware, redirects mapped and tested, analytics verified, Search Console live, rollback plan ready. DNS cutover happens at your low-traffic hour. The unglamorous truth is that a rehearsed launch is boring — which is exactly what you want from a launch.
6 · Handover from day one, not at the end
Documentation accumulates as the project runs: environment notes, credential map (your accounts, scoped access for me), feature decisions and why. At the end you receive the full handover pack — repository, accounts, documentation — and the project is genuinely yours. This is also insurance for me: a documented project is one where bus-factor is not a business model. See payments & terms for what happens after launch.
What this method costs you
Honesty cuts both ways: this process asks things of you too. Decisions on a schedule (design approvals, content deadlines), one primary channel instead of five, and feedback in consolidated passes rather than drips. Clients who engage this way get their best projects; clients who disappear for three weeks mid-build get longer timelines. The method is the product as much as the code is.
Sounds right?
The method fits one codebase with a clear owner — most business sites, stores and web apps. If you need six specialists by Monday, an agency is the honest answer.