Four principles.
No exceptions.
The way I run engagements does not change based on the client, the project size, or the price. These four principles are how you get consistent delivery from a one-person practice.
Scope in writing
Every engagement starts with a versioned scoping document.
Nothing is negotiated in chat threads or on calls that later get forgotten. Before code is written, we agree on the scope in writing: what is in, what is out, what it costs, what the timeline is, what the milestones are.
The document is versioned. If we later decide to change scope, we amend it and both agree. That is the record we come back to when memory disagrees.
Direct engineer access
You talk to the engineer building your work.
There is no project manager between you and the code. When you have a question, you ask me directly. When I have a question, I ask you directly. The turnaround is measured in hours, not days.
Slack, email, or scheduled review calls, whichever works for your team. I hold two weekly office hours slots for active engagements so you always have a predictable time to get eyes on your project.
Versioned artifacts
Every major deliverable is a versioned document.
Copy, brand context, technical plans, handover documents. Everything gets a versioned file. Not slides that get lost in a chat, not markdown scattered across a repo. Real documents you can print, hand to your team, or read a year from now.
This matters because engagements end. When ours ends, you should have a complete record of what was built, why it was built that way, and how to keep working with it.
Clean walk-away
You own everything. Support is a choice, not an inheritance.
Every custom build ships to your infrastructure. Every credential, every account, every domain is registered in your name. Every repository sits under your GitHub organisation, not mine.
When our engagement ends, you should be able to keep working with any competent engineer. Post-launch support is a retainer you can choose to take. It is never a lock-in you inherit.