Talk numbers
Work

Client stories: the question each business couldn't answer, what we built and what changed.

All work
Built

Tools we built, for clients and for ourselves, when nothing we could buy did the job.

Open to anyone

Runs our work

For clients

See all builds
AI

AI moves fast. Here's how we use it in our own work, and where to start in a business your size.

The AI hub
Approach

Every business is different, so we always start with a conversation.

How we work
  1. 15 minA quick callYour goals, your numbers, and whether we're a good fit.
  2. 1 hourDiscoveryWhere you're losing enquiries, and what's already working.
  3. ThenA clear planPaid ads, a custom build or both, as a one-off project or ongoing.

What we connect

About

We're a small London team of marketers, and we use AI to go faster.

About us
  • Cam BowenCam BowenCo-founder
  • Ben PowerBen PowerCo-founder
  • ElectraElectra
  • MahirMahir
  • NatashaNatasha
  • RahabaRahaba
  • ZobaerZobaer
Tool · Website

GitHub

  • Private repositories
  • Pull requests for code
  • Merge to main deploys
  • GitHub Actions

Where our code lives. Code changes are pull requests that are read first, and CMS edits are commits that run checks before they deploy.

Talk numbers All tools
  • 45repositories in our GitHub organisation, all private
  • 37of them with our shared Claude Code rules
  • 280+pull requests merged on this site since 22 September
  • 3builds on it
Why we use it

Why we keep code here

  • A record of every change

    Each commit records who changed what and when, and the message says why. If a change breaks something, we can see it and go back.

  • Code gets read first

    Pull requests give a person or Claude Code a chance to read a code change and run the checks before it joins the main branch.

  • A merge is a release

    On this site, merging to main runs the build and deploys staging in about a minute, with no one running a deploy command by hand.

  • CMS edits are tracked too

    Keystatic saves are commits, so an editor's change has the same history and the same way back as a developer's.

  • Limits that stop pile-ups

    At most five open branches per repo keeps old half-finished work from building up behind the live code.

  • Jobs that run on a schedule

    GitHub Actions runs checks, syncs and health checks on a timer, and we move the scheduled ones to our own small server to save minutes.

GitHub is where all our code lives, this website included. We keep it in private repositories, so there's a record of who changed what and a way back to any earlier version.

How a change gets live

  • Code changes are pull requests. Work happens on a branch and opens as a pull request. A person or Claude Code reads it and runs the checks before it merges.
  • A merge to main deploys this site. A GitHub Actions workflow builds it and sends it to Cloudflare. It takes about a minute, and it doesn't depend on one person's laptop.
  • CMS edits are commits too. When an editor saves in Keystatic, the save is a commit to this site's repository, and the content check runs before it deploys to staging.

Keeping it tidy

  • Five open branches per repo, at most. More than that and our tools tell us to merge or close something first. A session start also clears branches that are merged and idle.
  • Shared rules in 37 of 45 repos. Most repositories carry the same instructions file, so Claude Code works the same way in each.
  • A bot that reads them too. A Grok bot reviews pull requests for bugs and secrets. It also flags pushes that skip review and failed builds across 12 repositories, and files an issue. It doesn't merge anything.

Scheduled jobs on our own server

Some repos run daily jobs, like health checks and data syncs. On GitHub's free plan those add up, so we run the scheduled ones for a few repositories on a small server of our own. The deploys stay on GitHub's runners.

Even our docs

Our internal docs site, docs.pacing.agency, is built from a repository too. Merging to its main branch publishes it.

Wires

What we connect it to

On its own

A merged pull request isn't a working site. Someone still has to look at the result and check the tracking.

Claude CodeCursorAstro + KeystaticCloudflareGrokAnthropic
Proof

Where we've used GitHub

All our work

Services

Services that use it

We don't sell it on its own. Each of these services uses it alongside the rest of your setup.

How we start
About the tool

What GitHub is

GitHub is where teams keep code and the history of every change to it. Each change is a commit, and a pull request is a proposed set of commits that someone reads before it joins the main branch.

GitHub Actions runs automated jobs from the same place: checks, deploys and scheduled tasks. On the free plan, private repositories get 2,000 Actions minutes a month (GitHub's pricing page, October 2026).

Questions

Questions about GitHub

Straight answers on how we work, what it costs and what to expect. If yours isn't here, just ask.

Still have questions?

Talk to us
How do you plan and track client work?

We split each job into tasks, each with an owner and a date, on the task board in our CRM (Twenty). Code changes are tracked in GitHub as pull requests, and plans, notes and reports live in Google Docs and Sheets.

You don't need to log in to any of it. We keep you posted by email, on scheduled calls and in reports.

Read the full answer : How do you plan and track client work?
Notes

We've written about this

The Content Hub

Where next

Start with your numbers.

We'll tell you which tools you need and which connections are missing.

Trusted by teams across the UK and beyond

Next step

Bring your numbers.

We'll tell you if the spend makes sense.

  1. A 15-minute callYour goals, your challenges, and whether we're the right fit.
  2. A 1-hour discovery callWe dig into your numbers. Worth a hundred emails.
  3. A concrete planAds, a custom build or both, as a one-off project or ongoing.
Talk numbers
15 minutes · No pitch deck · A straight answer