Before design or development starts, we agree the outcome, scope, risks, responsibilities, cost and way of working. Security is shaped around the real system from the beginning, not added after the important decisions have already been made.
A maximum of 6 projects per quarter
Next intake opens 1 October 2026.
We map the business goal, users, sensitive data, integrations, constraints and budget before I recommend a direction.
You review the scope, exclusions, security responsibilities, timeline and payment schedule. Work starts after acceptance and the initial payment.
Architecture, access and safeguards are decided before sensitive features. You review working milestones as the project develops.
We check the agreed requirements and security controls, then arrange launch, access, documentation and ongoing support.
I prepare a proposal and agreement for your project and send you a private link. You can read it, print or save a copy, and record your acceptance on the page itself. The start conditions it sets out, including the initial payment, are met before work begins.
A clear way of working
You work directly with me, from the first conversation through to handover. I take on a maximum of six projects a quarter, so risks, responsibilities and decisions are not rushed or left implicit.
How projects startDeliverables, costs, revisions and responsibilities are documented before work begins.
Extra requests are scoped and priced separately, and only proceed once you approve them.
An enquiry or a discovery call does not reserve a slot. Work begins after acceptance and the initial payment.
I use a risk-proportional baseline from discovery through handover. Controls become stricter when a project handles sensitive data, money, privileged access, automation or business-critical operations.
Before architecture is fixed, I identify the people, data, integrations and failure cases that matter. A brochure site and an operational AI system do not receive the same controls.
Accounts, APIs, staff roles and automated tools receive only the access required for the agreed workflow. Secrets stay out of source code and public interfaces.
Approval steps, escalation paths and prohibited actions are defined before launch. Automation does not quietly inherit authority it was never given.
The handover covers access, failure behaviour, data handling, logging, recovery and known limitations. Open risks are documented instead of hidden behind a launch date.
The exact controls are agreed for the project. This is a delivery standard, not a claim that every system has the same risk or compliance requirements.
Tell me about the website, application or workflow you need. An enquiry is a conversation: it is not an agreement, and it does not reserve a project slot.
Discuss your project