Process
This is the mechanics of how I work in practice: how I quote on a piece of work, what you'll see from me each week, when I'll push back on something, and how the engagement ends well. The shape of it stays much the same whether you're a business hiring me directly or an agency partnering with me on a build.
Every engagement, big or small, runs through the same five steps. The shape stays consistent so there are no surprises about how the work will be planned, costed, built, launched and looked after, whether you're a business hiring me directly or an agency partnering with me on a build.
Honestly, not very much. A short written brief, a real deadline, and a rough sense of the budget band you're working in. There's no need for a 40-page RFP, just a paragraph of context, a list of the things you really need, a list of the things that would be nice if there's room, and any prior work you'd like me to read first. If you'd rather just talk it through, the discovery call covers the same ground in about 30 minutes.
I'll write the scope up for you in plain English, covering what's in, what's explicitly out, and what we're sensibly leaving open to look at later. The pricing comes back in three bands (lean, recommended, and ambitious) so you can choose the level of investment that matches the level of risk you want to take. We refine the proposal together, and you only sign it when it genuinely matches what you actually want to buy.
I tend to work in writing by default, with deep work happening through the day and written updates running across the week. Every Friday you'll get a short progress note covering what's shipped, what's in progress, anything that's blocked, and what I need from you next. There's an optional fortnightly call for the messier conversations that don't write down well. We won't be running daily standups, and there'll be no constant "just jumping on a quick call" either.
When done well, launch day should be a bit of a non-event. The migration plan, the rollback plan and the smoke tests are all written down well in advance, so we know what we're doing before anyone clicks anything. After launch I'll sit down with your team for a proper training session, hand over written documentation they can come back to, and stay on standby for the first fortnight while everyone settles in with the new site.
The code, the hosting and the accounts all belong to you from day one, never to me. Most clients stay on a monthly care plan after launch for the security updates, the framework upgrades and the smaller changes that come up, and some move onto a retainer for steady iteration alongside their team. Whichever way you go, you can hand the codebase off to any developer in future, because I don't lock anything up in proprietary tooling.
001 / Project
A fixed scope, a fixed price and milestone-based delivery, all set out in writing. This is the right shape for a clearly defined piece of work like a new build, a major feature, or a migration off something old. Most direct-client engagements actually start their life here.
002 / Retainer
Reserved monthly capacity for steady iteration, ongoing support and the smaller new builds that come up. This is the right shape for clients who have an ongoing roadmap and want to know there's a senior developer on call, without the overhead and commitment of a full hire.
003 / Advisory
An audit, a second opinion, technical due diligence on an inherited build, or fractional CTO support for a team that needs one. There are no code commits with this kind of work, the deliverable is a written report, a clear recommendation, or a regular standing call with your team.
We'll set a regular rhythm for the project. I'll send a written update every week, by Friday at the latest, so you and your team always know where things stand. There won't be daily standups or constant "quick calls" or surprise meetings dropping into the calendar. We'll add an optional fortnightly call for the messier conversations that don't write down well, and you can pick whether we use Slack or Teams. I'll sit inside your workspace under your domain.
The reasoning behind all of this is honestly pretty simple. I do better work when the day isn't fragmented into a dozen short interruptions, and you get a clear written record of progress that you can forward straight to a board update or a stakeholder without having to retype any of it. If something genuinely needs a real-time conversation, of course we have one. The default just stays as writing.
Code
Pull requests, code review and CI as standard. I work in your repo, on your branches, against your conventions. GitLab and Bitbucket are perfectly fine too if that's where your team lives day to day.
Tracking
Tickets, milestones and a shared roadmap document we can both look at. If you're already using Jira, Asana, ClickUp or Trello, that's perfectly fine, I'll happily come and meet you in whatever tool your team is already comfortable with.
Chat
Conversations happen in threads, with pinned weekly updates so nothing important gets buried. I sit inside your workspace under your domain. Email works perfectly well too for the slower, more considered conversations.
These are just my defaults, and I'll always adapt to your stack rather than the other way around. If you and your team are living in Basecamp, Monday, Discord or even carrier pigeon, I'll meet you there happily. The goal across the whole engagement is fewer tools to think about, not more.
In my experience, most projects that go sideways do so because one of four things is missing on the client side. If any of these is missing on yours, I'll flag it gently on the discovery call, not as a deal-breaker, just so we can plan properly around it together.
Need 01
One person on your side who has the authority to make decisions and who I can reach within 24 hours when I need to. Not a committee, and not a shared inbox.
Need 02
Whoever signs off on the scope, the copy and the design ideally needs to be the same person from start to finish, or to have very explicitly delegated that to someone else. Mid-project sign-off changes are honestly one of the most expensive things in software.
Need 03
DNS, hosting, repo, domain registrar and any third-party API keys. All of these stay in your name, with me as a collaborator on the accounts rather than the bill-payer.
Need 04
Real copy, real images and real product data (not lorem ipsum) ready by the milestone we've agreed together. We'll set that deadline as a team, and missing it is genuinely the most common cause of launches slipping.
And then the other side of the same conversation. These are the four things I commit to, in writing, on every engagement I take on, whether you're a small business, a large in-house team, or a partner agency I've worked with for years.
Commit 01
Reserved capacity in my calendar for the duration of the engagement, so I won't quietly overbook you against another project I should be working on.
Commit 02
Short, in plain English, of a quality you can paste straight into a board pack without rewriting it. No jargon, no talk of velocity, no story points to translate.
Commit 03
Standard frameworks, sensible architecture, README files that actually explain things, and a clear commit history. There's no proprietary lock-in, and no "only Dan can maintain this" magic to worry about later.
Commit 04
The senior developer you hired is the senior developer who actually builds the thing. I won't subcontract the delivery to a cheaper pair of hands halfway through the project.
Every engagement starts with a plain-English statement of work signed by both sides. There's a 30% deposit on signature to reserve the calendar properly, and then a milestone schedule for the rest of it, usually 30/30/40 split across kickoff, mid-build and launch. The final invoice is payable on launch, and intellectual property transfers across to you on final payment.
It's a UK contract, governed by English law, payable in pounds sterling by bank transfer. I carry professional indemnity and public liability insurance through a UK broker. NDAs are very welcome, either yours or mine, whichever your legal team prefers. For agency partners, your master services agreement and PO process replaces my SOW wherever you'd rather work that way.
Next step