Principal Delivery
Two shapes of engagement, one responsibility: the technical delivery reaches production and is handed over to someone who can run it.
Production Delivery Sprint
Get a stalled Azure integration into production, with one principal engineer owning the release, operational readiness and handover.
- Written acceptance tests for the agreed business flow and its failure cases
- Deployment automation, monitoring and rollback
- Reconciliation or recovery evidence where the flow needs it
- Code, a runbook and handover to a named operational owner
- A defined defect warranty, separate from ongoing operations
The two-to-four-week commitment starts when access, dependencies and acceptance authority are ready. Unknown third-party interfaces or unresolved business rules are quoted separately as investigation, or run at a day rate. A fixed fee cannot make another supplier cooperate.
Production Delivery Cover
When a lead is unavailable and a release cannot wait, I take ownership of the engineering work through production and handover.
- Ownership of the delivery backlog
- The open technical decisions closed
- Implementation and release coordination
- Handover to whoever picks it up next
An initial two-to-four-week block, agreed days, one named workstream. Responsibility for the agreed engineering work, without an unconditional fixed-price guarantee over a programme I have not yet seen.
Technical delivery leadership
Delivery decisions do not wait for a governance forum. Inside a scoped engagement I close the technical calls the release depends on - architecture, integration boundaries, build or buy, and what has to be true before anything can go live - and record them so the team is not left guessing. That leadership is part of the delivery, bounded by the same scope and finished on the same date. It is not a standing role and it does not sit on your org chart.
Weighing this against a part-time leadership arrangement? Where the line sits between the two models →
What can AI actually do?
AI is how the work gets built here, not what is being sold. Worth being precise about, because the honest answer is what makes it safe to buy.
What it does well
- Write and refactor at volume
Whole modules, migrations and test suites drafted in minutes rather than days.
- Read a system faster than a person
Trace a behaviour through an unfamiliar codebase and explain how it actually works, not how the documentation says it does.
- Do the work nobody schedules
Tests, documentation, error handling and the tidying that gets cut the moment a deadline arrives.
- Hold more context than a team
Every file, every config, every log line, without being briefed twice.
- Never get bored
The fiftieth integration endpoint gets the same attention as the first.
What it cannot do
- Know what you actually need
It answers the question it was asked. Deciding which question is worth asking is the job.
- Be trusted without checking
It is confident when it is wrong, and wrong often enough that unreviewed output is a liability rather than a shortcut.
- Judge a tradeoff
Reliability against cost, speed against auditability. Those are business decisions wearing technical clothes.
- Carry the consequences
Someone has to be accountable when a regulated system misbehaves, and it cannot be the model.
- Substitute for judgement
It multiplies whatever is directing it. Point it badly and it builds the wrong thing faster.
So AI is a multiplier on the engineering, not a replacement for it. On a DBHQ engagement the judgement, the review and the accountability are human, and they come from 26 years of building systems where getting it wrong was expensive.
Built for production, not the demo
Secure production AI
Deployed production, network-isolated AI coding assistance inside the secure boundary - and wrote the adoption patterns the engineering team uses
AI product, built solo
A complete AI-powered consumer platform - 28,000+ published products across 1,600+ brands, a recommendation engine, real-time price comparison and a mobile app - designed, built and launched by one engineer in months.
Regulated-grade cloud and integration
Enabled multiple COTS vendors to develop and integrate on the platform. Sole cloud architect for the Azure infrastructure behind a UK digital identity platform interoperable with the major consumer identity wallets.
Most of this work is Azure integration, and the component choice is usually made before anyone asks what it costs to run. Which Azure Integration Services component fits which problem →
Questions, answered
- Who actually writes the code?
- I do, with AI doing the typing. The distinction matters: I decide what gets built, how it is structured and what is acceptable, then direct AI to produce it and review everything before it goes near your systems. Nothing ships that I have not read and understood. What you are buying is the judgement, the review and the accountability - the same code ownership, the same handover and the same person answerable for it as you would get from work typed by hand.
- What does it cost?
- A Production Delivery Sprint is a fixed fee for a bounded release, agreed once I have seen the code, the dependencies and the acceptance criteria. Delivery Cover is agreed days against one named workstream. Where the work cannot yet be bounded, I quote the investigation separately rather than hiding it inside a price. Scope, price and acceptance criteria are agreed in writing before work starts.
- How long does it take?
- A Sprint is scoped as a two-to-four-week block, and that block starts when access, dependencies and acceptance authority are ready - not when the paperwork is signed. Cover starts as an initial two-to-four-week block against agreed days. I will not put a date on a release before I have seen what it depends on.
- Can you work with what we already have?
- Yes, and it is the usual case. I start from the code, the pipeline and the integrations you already have, establish what works and what has to change, then build from there rather than replacing it by default. What exists remains yours, and so does everything added to it.
- Who owns the code and data?
- You do. Code, documentation, data and tooling stay in your own accounts, and handover to a named operational owner is part of the work rather than a favour at the end. There are no licences to DBHQ and nothing to unpick if the engagement ends.
- What access do you need?
- Enough to understand, test and release the systems the work touches. Read-only access to code, configuration, logs and the relevant documentation is enough to scope it; anything that changes a production system is agreed separately and in writing.
- Are you tied to a model or vendor?
- No. The work is model- and vendor-independent. I use the model, platform and deployment pattern that fit your outcome, data and operating constraints, including what you already have where it remains the right choice.
- How does it start?
- With a short call to establish the release, what is blocking it and who has to accept it. If the work can be bounded, you get a fixed price and the acceptance criteria in writing. If it cannot be bounded yet, I say so and quote the investigation that would make it possible.
Start dates and working days are agreed before commitment. Code and delivery documentation are maintained in agreed client-accessible locations. Continuous support and guaranteed emergency cover are not included.
Fifteen minutes will tell you if this fits
Bring the problem - the stalled pilot, the systems that do not talk, the manual process eating your team. You will get a straight answer on whether it is sprint-shaped, roughly what it would cost, and when it could be running.
I reply within 24 hours