Skip to main content
Duspat

Delivery Approach

From unclear ambition to production-ready delivery

Seven stages, six ways to engage, and a definition of “production-ready” we are willing to publish and be held to.

The Duspat delivery model

Seven stages. Most consultancies stop at five.

Govern and Enable are stages, not footnotes. Skipping them is the single most reliable way to produce something impressive that nobody can operate, afford or defend twelve months later.

  1. 01

    Discover

    We map what is actually true before proposing anything: the data you hold, the obligations attached to it, the systems that cannot move, and the decisions already taken that cannot cheaply be unwound. Most bad architecture is a reasonable answer to a misunderstood question.

    What you get

    A constraint map and a shared, written understanding of the problem.

  2. 02

    Assess

    Platform, pipelines, governance, quality and capability — measured rather than self-reported. This is where we say the uncomfortable thing early, while it is still cheap to act on, rather than discovering it in month four.

    What you get

    A maturity baseline, a risk register and a prioritised gap list.

  3. 03

    Architect

    Target architecture, HLD and LLD, data models and platform patterns. Every architecture has a cost; we name it before you buy it, and we write down why the rejected options were rejected — because in eighteen months somebody will ask.

    What you get

    HLD, LLD, a costed roadmap and a decision log.

  4. 04

    Build

    Infrastructure as code, automated tests, observability and cost controls are part of the build rather than a phase we promise to return for. Delivered alone or embedded alongside your engineers, depending on what you actually need.

    What you get

    Working software, with the tests, pipelines and telemetry that make it supportable.

  5. 05

    Deploy

    CI/CD that turns a release into a routine rather than an event, environments reproducible from code, and a rollback path that has actually been exercised — not one that exists on a slide.

    What you get

    Automated pipelines, reproducible environments and a tested rollback.

  6. 06

    Govern

    Access control, lineage, retention, audit trails and data quality checks with named owners. Governance that exists only in a document is not governance; it is a liability with better formatting.

    What you get

    Enforced controls, monitoring that reaches a human, and named owners.

  7. 07

    Enable

    The engagement ends properly or it does not end at all. Standards, documentation, runbooks and hands-on mentoring, so the capability stays with your team. If they cannot operate it without us, we have not finished.

    What you get

    Runbooks, standards, documented handover and a team that can run it.

Engagement models

Six ways to engage.

So you know roughly what you are asking for before the first call — and so we can both tell quickly when this is not a fit.

  • Advisory sprint

    2–4 weeks

    A focused engagement on a decision you are stuck on — platform selection, an architecture you inherited, or an initiative that has stopped moving and nobody can say why.

    You end up with. A costed recommendation and a written decision log.

    Best when. You need a defensible answer quickly, from someone with no stake in the outcome.

  • Architecture assessment

    3–6 weeks

    An independent review of an existing platform, pipeline estate or AI system: what it does well, where it will break, what it will cost, and what to do about it.

    You end up with. A findings report, a risk register and a prioritised remediation plan.

    Best when. You have inherited something, or you are about to bet a roadmap on it.

  • Proof of concept

    4–8 weeks

    A narrow, honest test of a specific technical question — a RAG pattern, a streaming approach, a platform migration path — built to production standards so the result actually means something.

    You end up with. A working proof, an evaluation against the original question, and a clear recommendation.

    Best when. You need evidence rather than opinion — including evidence that the idea does not work.

  • Production build

    Project-based

    Hands-on delivery, alone or embedded alongside your engineers, taking a design through to a governed service running in production.

    You end up with. A deployed, governed, documented service — and a team who can run it.

    Best when. You need it built, not advised on.

  • Fractional architecture leadership

    Ongoing, part-time

    Senior technical leadership for organisations that need the judgement and the accountability without the permanent headcount.

    You end up with. Architecture ownership, standards, technical governance and honest counsel in the room.

    Best when. You need a senior architect in the conversation, but not five days a week.

  • Team enablement and training

    Programme-based

    Hands-on mentoring and role-based enablement on production-ready pipelines, APIs, event-driven architecture, CI/CD and AI workflows — built around your systems, not a generic curriculum.

    You end up with. A team that can build and operate this without us, and the standards to keep doing so.

    Best when. The capability gap is the actual problem, and buying delivery would only defer it.

Governance & risk

Governance is designed in, not added later.

Every control below is cheap to decide during design and expensive to retrofit after go-live. That asymmetry is the whole argument.

It is also, in practice, what unblocks AI programmes. Most stall not on the model but on an unanswered risk question that nobody has written down.

Classification before architecture
What the data is, how sensitive it is and who may see it — decided before a platform is selected, because those answers change the platform.
Access modelled, not accumulated
RBAC and least privilege designed at architecture time. Permissions that accrete over three years are not an access model; they are a liability nobody has measured.
Lineage and metadata
Where a number came from, what transformed it, and what breaks if the source changes. Without this, a data platform cannot answer the only question that matters in an audit.
Quality as a control, not a dashboard
Automated checks with named owners and a remediation path, so a bad load fails loudly rather than propagating quietly into a board report.
Retention, residency and regulatory obligations
Mapped to the target state at design time — including GDPR-related controls, retention schedules and the right to erasure.
AI risk controls
Acceptable-use boundaries, human oversight, entitlement-aware retrieval, evaluation and audit logging. The control model is designed before the model is chosen.

Production readiness

What “production-ready” actually means.

The phrase is worthless unless it is enumerated. This is our list. We will hold an engagement against it, and you should hold us to it.

Build

Infrastructure as code
Every environment reproducible from a repository, reviewable in a pull request, and destroyable without ceremony.
Automated deployment with a tested rollback
Not a rollback plan. A rollback that has been executed at least once, deliberately.
Tests that would actually fail
Coverage of the paths that matter, including the failure paths — and a build that goes red rather than warning quietly.

Operate

Monitoring and alerting a human receives
An alert that fires into an unread channel is not monitoring. Somebody is named, and they are expected to act.
A documented cost model
What it costs to run, what drives that cost, and what happens to the bill when volume triples.
A runbook
What breaks, how you would know, and what to do about it at 3am — written before it is needed.

Govern

Access control and least privilege
Who can reach what, justified rather than inherited, and reviewable without archaeology.
Audit logging
A record of what happened, who caused it, and when — retained long enough to answer the question you have not been asked yet.
Data quality checks with named owners
A check nobody owns is a check nobody fixes. Ownership is part of the control, not adjacent to it.
A named owner after handover
The engagement is not finished when the code ships. It is finished when somebody else is accountable for it.

How we work

The commitments underneath all of it.

  • We write things down

    HLD, LLD, decision logs and runbooks are deliverables, not afterthoughts. If the reasoning only exists in someone’s head, it does not survive their next role.

  • We design for the team that stays

    If your team cannot operate it, we have not finished. The measure of an engagement is what works six months after we leave.

  • We are specific about trade-offs

    Every architecture has a cost — in money, in complexity, or in the option it forecloses. We name it before you buy it.

  • We do the work

    You speak to the person who designs and builds it. No pyramid, no bench, no handover to a delivery team you have never met.

  • We would rather tell you not to

    If a simpler answer exists, or AI is the wrong tool for the problem, we say so — even when the larger engagement would have been ours.

Tell us where you are stuck.

Whether that is an unclear ambition, an architecture you have inherited, or a pilot that cannot get past a security review — the first call is technical, not a sales call.

Book a consultation

30 minutes, no pitch deck.