An accountable workflow for page updates

Product marketing told me something that stuck. Once a marquee product page ships, it's pretty well set. In practice PMM almost never rewrites one of these pages. It's a copy fix here, a new related resource at the bottom there. Small, specific edits.

That got me thinking about what these pages actually need behind them. If a page barely changes after launch, does it need a whole CMS at all? More and more, a page like this can be built by an AI agent, directly as code, with no page-building framework underneath. No WordPress, no Webflow, no headless CMS. It's fast, it's fully custom, and there's a lot less machinery to keep running.

But it raises an obvious question. If the page is just code, with no admin screen behind it, how does a marketing team make those small edits? You can't hand product marketing a login to a CMS that isn't there.

No CMS, no editor, no trail

With WordPress or Webflow, a marketer opens the page and edits it. That works, we build plenty of sites that way, and you get at least some record of who changed what. A framework-less, AI-built page gives you neither by default. There's no editor to hand someone, and no trail. So before you build pages this way for a real marketing team, you have to answer the publishing question: how does a change get made, reviewed, and shipped, on the record.

Route every change through a workflow

Here's the idea I've been kicking around. The workflow becomes the part you'd normally get from a CMS, except it's assembled from tools the team already uses. Keep it self-serve, but route every change through a path that leaves a record on both ends. One or more entry points feed in, and a real paper trail comes out.

Here's each step:

Where the record lives

The part I like most is where the trail lives. Every request ends up in two places at once: the Asana task or Slack thread it came from, and the pull request. Both are open to anyone who follows them. Nothing happens in a corner.

Because it's all structured, you can pull it into a dashboard. Every update in one view, filterable: what changed, when, who asked, who approved. That's more visibility than a CMS admin gives you, on pages that never had a CMS in the first place.

Artifacts, so it's not a black box

There's one more piece that makes this reviewable instead of a leap of faith. Claude writes an artifact at every step. By artifact I mean a copy of the full session, verbatim: the reasoning, the decisions, the actions it took. We ask for plain summaries too, but the artifact is the real record. When it does something surprising, or gets stuck, you can go read exactly where and why.

› read issue #482  "update the ROI footnote on /product/graph"
› plan     1 file  · src/pages/product/graph.astro
› edit     applied · footnote text + source link
› branch   fix/issue-482  → preview building…
› staged   https://issue-482.preview.redbridgenet.com
› pr       #1207 opened  · summary posted to the thread ✓

The model is swappable. The infrastructure is the point.

Claude does the work here, but Claude isn't the foundation. The foundation is the stack the pages already live on: the repo, the branch previews, CI, and the task tool your team already uses. Together, that's the CMS you didn't build. The model that reads a request and makes the edit is one piece in the middle. When something better than Claude shows up, you swap that piece and the rest stands. We extend and adopt onto what we own. The infrastructure stays composable, and it stays yours.

This same workflow can front a WordPress or Webflow site too, and you get the same paper trail on every change. But it matters most on the page that has no CMS at all, where it's the only way anything ships.

This is the kind of workflow we're putting together for the enterprise SaaS teams we work with here in the Bay Area, whether their pages run on WordPress or get built straight in code. If you've got a marquee site and you want changes to be both easy and on the record, reach out. We're here for you.