# Agencies & Software Houses

Source: https://www.jawsdeploy.net/solutions/agencies

Agencies live or die by repeatability. A deployment that works for one client should work for the next twelve - without copy-pasting last quarter's pipeline. Jaws Deploy gives you templates that travel, environments that stay isolated, and an audit trail your account managers can actually read.

## 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.

> **// The hidden agency tax - Every new client used to cost you a week of deployment setup.**
> 
> Twenty clients per year, one engineer-week each, billed at agency rates. That is the line item nobody writes down. The agencies that grow without imploding are the ones that turned 'set up the deployment' into a fifteen-minute task. That is what reusable step templates and shared variables actually buy you.

## 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.

**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.

**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.

> **// Sharp edge for agencies - Variables and secrets do not travel between workspaces. On purpose.**
> 
> If you choose 'workspace per client', do not try to share a database password across workspaces. The platform won't let you - it is designed to keep one client's secret out of another client's deployment context. Plan your structure with that constraint in mind from day one.

## 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**.

## 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.

## 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.

> **// What this means for renewals - Reliability is a sales pitch. Audit trails are evidence.**
> 
> When a client renews, the question they ask their procurement team is: 'did this agency cause us deployment problems?' If the answer comes from Jaws Deploy's history, it comes with timestamps, durations, and a clear 'yes/no'. If the answer comes from chat history and Word docs, it tends to go badly. The platform's existence is a renewal asset.

## 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.