Skip to main content
Duspat

Service

Build & Deployment of Client Services

Cloud-native services designed, built and deployed to a production standard — with the infrastructure as code, pipelines and engineering practice that make the next release boring.

Who it is for

  • An organisation that needs a service built, not merely advised on
  • A team with a design, a deadline, and no spare senior capacity
  • An engineering leader whose deployment practice needs to grow up before the next audit

Problems we solve

What tends to be going wrong.

The architecture never survives implementation
A design document that describes a system nobody built, because the decisions that mattered were made at the keyboard by whoever was available that sprint.
Environments assembled by hand
A production environment that cannot be reproduced, because the person who clicked it into existence has left and the console is the only record.
Deployment is an event
Releases scheduled for a Thursday evening, with a rollback plan that has never been tested. The cadence slows, the batch size grows, and the risk compounds.

How we help

What Duspat delivers.

01
Secure service builds
Client-facing and internal services built to a production standard — web applications and portals, APIs, serverless backends, data products and dashboards.
02
Cloud-native and event-driven architecture
API Gateway, Lambda, Step Functions, EventBridge, DynamoDB and ECS, sized for the workload you actually have rather than the one on the vendor slide.
03
Infrastructure as code and CI/CD
Terraform, CloudFormation and SAM; pipelines in GitHub Actions, GitLab CI or CodePipeline — with reusable workflows, pre-commit checks and semantic versioning.
04
Observability and operational readiness
Logging, metrics, alerting that a human actually receives, a tested rollback path, a documented cost model and a runbook. Then a real handover.

Typical deliverables

Things you can hold, review and hand to a team.

Design-and-build, or a delivery-uplift engagement that leaves your team with the practice rather than a dependency on us.

  • Web applications, portals and internal tools
  • APIs and serverless backends
  • Data products and dashboards
  • Cloud-native and event-driven service architecture
  • Infrastructure as code (Terraform modules, CloudFormation, SAM)
  • CI/CD pipelines with reusable workflows, pre-commit checks and semantic versioning
  • Static hosting on S3 and CloudFront where it is the right answer
  • Observability, alerting, runbooks and documented handover

Technology fit

What we build this on.

We are independent: no reseller agreements and no partner quotas. If your estate points a different way, we will say so.

AWS
  • Lambda
  • API Gateway
  • Step Functions
  • EventBridge
  • DynamoDB
  • ECS
  • S3
  • CloudFront
Infrastructure as code
  • Terraform
  • CloudFormation
  • SAM
CI/CD
  • GitHub Actions
  • GitLab CI
  • AWS CodePipeline
Runtime
  • Docker
  • Kubernetes
  • Helm
  • Node.js
  • Python
  • TypeScript

Governance & production readiness

Designed in, not added later.

Security and operability are build-time properties. A service that reaches its first security review without them does not get remediated — it gets delayed.

How we run an engagement

  • Least-privilege IAM and secrets management from the first commit
  • Infrastructure as code, so every environment is reproducible and reviewable
  • Security headers, TLS and origin access controls on anything public-facing
  • Audit logging and monitoring wired in before launch, not after an incident
  • A tested rollback path and a runbook with a named owner

Example outcomes

Evidence, not testimonials.

Anonymised and sector-level. Client names are withheld by design — the constraint and the architecture are the parts that carry any information.

  • Media

    Event-driven platform for financial royalty reporting

    The constraint. Highly variable volumes, financial accuracy, and reporting that has to withstand an audit.

    An event-driven AWS architecture that scales with volume rather than with headcount, and where every figure can be traced back to the event that produced it.

    • API Gateway
    • Lambda
    • Step Functions
    • EventBridge
    • DynamoDB
    • Glue

  • Multi-sector

    Engineering standards that outlast the engagement

    The constraint. Delivery teams shipping inconsistently, with standards that existed as documents nobody followed.

    Reusable CI/CD workflows, Terraform modules, pre-commit checks and semantic versioning, delivered alongside hands-on mentoring — so the practice stayed with the team after we left.

    • Terraform
    • GitLab CI
    • GitHub Actions
    • Pre-commit
    • SemVer

Related services

Questions

Common questions about build & deployment.

Can you build and deploy the service, or only design it?

Both, and the same person does each. That is the point of the practice: an architecture that never survives implementation is a common and expensive failure, and it happens when the people who designed it are not the people who have to build it.

What does infrastructure as code give us in practice?

Environments you can reproduce, review in a pull request, and rebuild after a bad day. The real benefit is not automation but accountability: a change to production becomes a diff somebody approved, rather than something a person did in a console at some point and cannot now recall.

What does a production-ready CI/CD pipeline include?

Automated tests that would genuinely fail, a build that goes red rather than warning, reproducible environments, a deployment that requires no manual step, and a rollback that has actually been executed at least once. A rollback plan that has never been run is a hypothesis, not a control.

How do you hand over a service so our team can run it?

With runbooks, standards, documented architecture and hands-on mentoring — and by having your engineers involved in the build where possible. If your team cannot operate it without us, we have not finished, whatever the contract says.

Talk through a service you need built properly.

A first call is technical, not a sales call. Bring a problem, an architecture, or a stalled initiative.

Book a build conversation

30 minutes, no pitch deck.