How I work
Agentic delivery, with a person in charge.
The loop
One process, every build.
- Written goal and definition of doneAgreed in writing before anything is built
- Architect agent plans work packages in wavesEach package small enough to test on its own
- Builder agents work in parallelSeparate lanes, separate workspacesFour lanes at a time, for example
- Tests and code scanning on every changeAutomated, every time, no exceptions
- Gary reviews every changeA human reads it before it is mergedAnything found goes back to the builders as a fix.
- Completeness reviewChecked against the definition of done
- ShipBuilt and tested; hardening follows
The document chain
Four documents, each one yours.
- Step 1 / PCD
Product Concept
Frames the problem and tests whether it is worth building at all.
You receive
- The problem in plain words
- An honest view on whether to build it
- An investment case and payback model
- Step 2 / FDD
Functional Design
Turns the concept into something buildable and testable.
You receive
- Processes and user journeys
- Numbered requirements and permissions
- Screens, data and a traceability matrix
- Step 3 / SBD
Solution Blueprint
The technical design for how it will be built, run and handed over.
You receive
- Architecture, data model and security
- Integrations, hosting and running costs
- Decision records, phasing and exit
- Step 4 / Pack
Branded delivery pack
The same documents, finished to send to a board or a supplier.
You receive
- Word and PDF versions, branded
- Cover, contents and consistent layout
- Yours to keep, whoever builds it
Guardrails
Fast, but fenced in.
Every change is reviewed
I read every change before it is merged. The agents propose; I decide.
Tests on every change
Automated tests run each time, and work is checked against the written definition of done.
Code scanning
Static analysis and security scanning run on every change, not just at the end.
Nothing deleted that the agents did not create
Agents may only remove what they made themselves. Your existing data and files are off limits.
Secrets stay in vaults
Keys and credentials live in a proper secrets store, never in code or in a prompt.
Client data stays in covered services
Your data only goes to services that sit under a data processing agreement.
Honesty
What AI is bad at.
- Knowing what you meant. Vague requirements get filled with confident, plausible guesses, so the goal is written down first.
- Your history and politics. It does not know why the last project failed or who has to agree before anything changes.
- Saying it is unsure. Wrong answers arrive in the same tone as right ones, which is why every change is read by a person.
- Judgement on novel trade-offs. Architecture decisions with real consequences stay with me.
- Staying on course over a long task. Work is cut into small packages so drift is caught early.
Questions
AI and safety.
Is AI-built software safe to run my business on?
It is as safe as the process around it. Every change is planned, reviewed by me, and proven by automated tests before it merges. Code scanning and security analysis run on every change. The AI does the typing; I am accountable for the result.
How do you keep our data private when using AI?
Your data stays in services covered by a data processing agreement, with enterprise AI endpoints that don't train on your data. I set out exactly where data goes before any build, and I use the least data needed for the job.
Where does AI not help?
Where the process itself is broken, where the data is poor, or where a simple rule would do. Many of the best outcomes I deliver are a process change or a better use of software you already own. I'll tell you when that's the case.
Next step
Tell me what's stuck.
In 30 minutes you'll know whether to fix it, buy it, build it or leave it. No pitch deck.