GTM as Code

The checklist

• Every client system lives in a git repo
• Workflows exported and versioned through the Clay API and CLI
• A snapshot exists before every change
• Changes reviewed as diffs, not eyeballed in a browser
• Test runs on sample rows before production tables
• Secrets in a vault, never inside workflow configs
• An architecture document a new operator can follow
• Approval gates enforced in the pipeline, not by memory
• Rollback rehearsed, not just theoretically possible
• The client can read everything in their own repo

Click-ops is how revenue systems rot

Most GTM automation lives in browser tabs: a table someone configured, a workflow someone tuned, a setting someone changed last spring. Nobody remembers why. When that person leaves, the system becomes an artifact nobody dares touch. The best work in most companies lives in heads, and dies with departures.

Software solved this decades ago with version control, review and rollback. In 2026 the same discipline is finally possible for GTM: Clay ships an API and CLI, workflows can be managed as files, and agents can operate the whole loop. What was a spreadsheet you babysat becomes a system you engineer.

One repo per client system

The layout is boring and that is the point: a workflows directory for exported Clay definitions, a sequences directory for outreach copy and cadence, docs with the architecture and decisions, and monitoring configs beside them. The repo is the system. Everything else is a runtime.

Ownership follows from structure. When the repo belongs to the client, the endless agency lock-in question answers itself: leaving means keeping the folder.

Build fast, then commit

The Clay UI is still the fastest place to prototype a table. The discipline is what happens next: export the workflow through the CLI, commit it, and from then on treat the UI version as a build artifact. Snapshots before every change make rollback a command instead of an archaeology project.

Think in functions, not tables. Most tables are combinations of smaller reusable steps: find the decision maker, run the email waterfall, validate, score. A library of functions compounds across clients and campaigns. A folder of one-off tables does not.

Review and test like it is software, because it is

Every change ships as a diff someone else could read: which columns changed, which provider moved in the waterfall, what the trigger condition became. Before a workflow touches a production table it runs on a sample of rows, and the output gets eyeballed against expectations. Ten minutes of sample review has caught every five figure credit burn we have seen coming.

Secrets never live inside workflow configs. API keys sit in a vault or environment bindings, so sharing a workflow never means sharing access.

Gates live in the pipeline

The promise that a human approves outbound is only real if the system enforces it. The approval step is part of the workflow definition itself: drafts queue, a person clicks, the log records who and when. Culture forgets. Pipelines do not. The full pattern has its own playbook.

Documentation is the handover

One architecture document per system: what exists, why it exists and what would break if you removed it. Written for the reader who was not in the room, because eventually every reader was not in the room. When a client hires their first GTM engineer, the onboarding is reading the repo, and it takes a day instead of a quarter.

Five ways code-less GTM burns you

1. Everything stays in the UI

   Six months of tuning with no export means the system exists only as long as nobody touches it.

2. No snapshot before the change

   The one afternoon you skip it is the afternoon a waterfall rewrites three thousand rows.

3. Keys pasted into configs

   Shared workflow, shared credentials. Rotating a leaked key hurts more than a vault ever will.

4. Clever without a reader

   An automation only its author understands is technical debt with a salary requirement.

5. Docs postponed forever

   Undocumented systems do not survive their creators. That is not a risk, it is a schedule.

What good looks like