Pacing Spaces

Each client we work with gets a small private site of its own, at its own pacing.agency address, where the work lives in one place: the meeting bar with the last and next meeting, the next steps, the links that matter, and a form to ask us for something. We built it because the first one, made for a single client, was never going to survive being copied twelve times. So there is one engine, and each client is a short config file on top of it.

It's internal for now: every space is up, and only our team can open them.

What a client gets

• A home page that fits them. A paid-search board, a tool page, a tracking page or a report with numbered chapters, chosen per client.
• The meeting bar. On every page: when we last met and when we meet next.
• Next steps and quick links. No hunting through email for the proposal or the last set of notes.
• A request form. A client writes what they need, picks a category and can drop in a screenshot. It lands in our CRM as a client request, and Ben and Cam get an email.
• Nothing sensitive. No personal enquiry details and no invoice files, only the status of things.

What the team gets

A staff hub, for Ben and Cam only. It has a morning view of open and overdue tasks, open client requests and the spaces we host, a page per client, the tools each client uses, and a requests list you can filter by client. An access page shows who can open what and flags where that's drifted from what's actually switched on in Cloudflare. Deploys and access changes are queued from the hub, with a log of who asked for what.

How access works

Cloudflare Access is the lock: Google sign-in, named email addresses only, never a whole domain. Both Workers also check the sign-in token themselves and refuse the request if it's missing or wrong, so a mistake in one place doesn't leave a door open. Access is set up before a space is deployed, so an address is never public, not even for a minute. Pages are marked noindex, and the default Workers addresses are switched off.

How it's put together

It's two Cloudflare Workers in one repo. One is the client-space engine: it reads each client's config from our ops repo, builds static pages, and runs a small request endpoint. The other is the staff hub. Client facts (address, who can sign in, links, meeting dates) stay in the ops repo, not in the engine, so the engine can be shared without the facts leaking into it.

It's built for how we work, so the alternative, a hand-made dashboard for every client that slowly goes out of date, never happens.