The agency deployment shape

An agency or software house has a problem most product teams don't: the deployment is part of the deliverable. The first time you ship for a client, you build a deployment. The next time, you do it again. The tenth time, you copy a pipeline from a previous project and slowly diverge it. By the twentieth client, nobody can answer 'which version of the deployment script does this client use'.

Jaws Deploy treats that as the central problem. Templates are first-class. Per-client isolation is the default. The deployment knowledge stays with the agency, not buried inside one client's repo.

How isolation works without copy-paste

A workspace per client (or per business unit, or per practice area) gives you a clean separation: variables, secrets, environments, agents, deployment history. Then step templates and script modules live above the workspace level - so the deployment patterns that work for Client A automatically apply to Client B without sharing any sensitive data.

Three layers that keep agencies sane

Workspace per client Each client gets a clean tenancy. Variables, secrets, agents, deployments - none of it leaks between clients, ever. Account team-by-account team access if you want it.
Shared templates Your library of reusable step templates - 'Deploy IIS site', 'Run migration', 'Swap blue-green' - is authored once and used in every workspace where it fits.
Project per service Inside a client workspace, one project per deployable thing. Same pattern across every client. New engineers onboard once and recognize the layout everywhere.

The two patterns agencies actually use

In the field, agency setups tend to converge on one of two shapes. Both are fine. Picking deliberately matters more than picking the 'right' one.

// Pattern A

One workspace per client

Clean isolation. Each client gets a dedicated workspace. Templates and modules are duplicated into each one or pulled from a shared library. Best when clients have strict data isolation requirements or when each client has very different infrastructure.

// Pattern B

One workspace, projects per client

Less isolation, less overhead. All client work happens in a single workspace, with each client as a project (or group of projects). Best when client deployments are similar and your team prefers one pane of glass.

What the deployment process looks like for the tenth client

The shape we hear back from agencies that have run this pattern for a year or two: the first client takes a week. The second client takes a day. The tenth client takes an afternoon. The improvement curve is real, and it comes from one specific thing - the templates compound.

// What a fast client onboarding looks like

From signed contract to first deployment

This is a real, abbreviated checklist from an agency running ~40 active client workspaces.

# 1. Create workspace for the new client (5 min)
New-JawsDeployWorkspace -Name "AcmeCorp"

# 2. Apply the agency's standard project template (10 min)
Import-JawsDeployProjectTemplate `
    -Workspace AcmeCorp `
    -Template "WebApp-IIS-Standard"

# 3. Register the client's machines, tag them (15 min)
Register-JawsDeployMachine -Workspace AcmeCorp `
    -Name "acme-staging-01" -Tags @("role:app","env:staging")

# 4. Fill the client-specific variables (20 min)
Set-JawsDeployVariable -Workspace AcmeCorp `
    -Name "Db.ConnectionString" -Value $clientConnection

# 5. Trigger first release from existing CI (10 min)
# Total: ~one hour for a setup that used to be a week.

Audit trails the account team can read

Agencies have a reporting problem that product teams don't. The client wants to know: was the patch deployed before the SLA window expired? Did the release that broke the cart get rolled back within an hour? Who actually pressed the button?

Deployment history in Jaws Deploy answers those questions in the UI. Filter by client workspace, by environment, by date range. Hand the URL to the account manager. Move on.

// Reporting that just works

What the client-facing side of an agency actually asks for

  • Per-client deployment exports - CSV or REST API, filterable, ready for a status report.
  • Time-to-recover metrics - rollback frequency and duration, per client.
  • Release attribution - which engineer triggered which deployment, on which release, on which day.
  • SLA-friendly timestamps - everything is in UTC, immutable, and exists six months later.
  • Plain-English release notes - whatever your CI puts into the release at creation time is preserved with the release forever.

The longer-term play

Agencies that grow into product companies (a common arc) tend to keep their deployment platform. The patterns you build for client work become the deployment patterns for your own products. The templates already exist. The team already knows the model. There is no migration moment.

That is why we lean on the agency case so hard - it is the test case for whether the abstractions scale across very different infrastructures, very different team sizes, and very different requirements. If we get this right, the rest is easier.