A typo, a price, a page — the words on your site, and who changes them.

1. 1

   A word

   A typo, a price, a sentence rewritten. The smallest kind of change, and by far the most common one.

2. 2

   A picture

   A photo swapped, a logo updated, or an image replaced with a lighter one — along with the alt text a screen reader speaks for it.

3. 3

   A whole new page

   A page that does not exist yet, added to the site and linked from somewhere a visitor actually reaches.

• A static build

  Every word and picture lives in the repository, as a file. Changing one is a change to that file, reviewed the same way as any other line of code. See Repository.

• A CMS-driven app

  Words and pictures live as rows a database holds, not files in the repository. Changing one is a row update, made through whatever admin screen the app itself provides. See Databases.

• A headless CMS

  Content sits in an outside service, and the site's build or app fetches it from there rather than holding it. A record lives there permanently, not just passed through on a single call. See Outside services.

1. 1

   You notice it

   You

   A wrong price, a typo, a page that is missing. Nothing here watches for this. A person reads the page and sees it.

2. 2

   You describe it in plain language

   You

   Say what to change and where it appears. No ticket template, and no technical wording — see Brief a change for the five parts of a good one.

3. 3

   Briefed as a change

   CustomLabs

   Written up the same way any other change request is. The iteration add-on is what covers it.

4. 4

   An agent opens the pull request

   CodeHerder

   The change lands as a real pull request against the repository, with the test suite run against it.

5. 5

   A human reviews and merges

   CustomLabs

   Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.

6. 6

   It ships through the same pipeline

   CustomHosted

   The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.

7. 7

   You're told it's done

   CustomHosted

   A note confirming what changed and that it merged, in the same shape as every other note on this site.

• Static site

  None — there is no running process to restart.

• Dedicated instance

  A few seconds while the process restarts. A health check confirms it answers correctly before the window closes.

• Managed database, minor version

  A brief connection blip during failover — existing connections reconnect on their own.

Private by default. Not linked from anywhere on your live site, not submitted to a search engine, and left out of the sitemap. Reaching it is a matter of knowing the address and being allowed in — access is controlled, not just unlisted.

• Revert the merge

  The same pipeline that shipped the change redeploys the last known-good version. No data touched, because none was.

• Promote the previous deploy

  On static hosting, the last deploy is already built and kept. Going back is a request through the usual channel, a straight promotion of it rather than a rebuild.

• A data problem is a restore, not a rollback

  If the thing that's wrong is data rather than code, that's the other procedure entirely — see Recovery for the backup and point-in-time paths, and where that boundary actually sits.

• A word or a picture is a briefed change

  Agentic iteration — CodeHerder ($25/mo) covers it, the same as any other small change. Brief a change in plain words. An agent opens a pull request, a person reviews it, and the same pipeline ships it.

• It draws from the same iteration allowance

  3 changes a month, 2 hours each — the same allowance a config change or a new page draws from.

• A brief that needs pricing first is quoted flat

  Quoted within one business day if the change itself needs pricing before anyone starts on it.

• This site is the worked example. It has 87 routes, 134 glossary terms, and 37 guide sections. Each one is a word or a page, written and shipped the same way a client's would be.
• 3 of the checks that run on every deploy here guard content directly. One confirms a page's own index still matches its bands. One confirms the machine-readable directory lists every route once. One confirms every route still carries one title, one description, and valid structured data. See Being found.

• A picture too heavy for the page budget

  Owner: You, briefed through CodeHerder

  A large image can push a page past its own published weight budget. Resizing it before it ships is part of the same briefed change. See Images.

• A new page nobody linked to

  Owner: You

  A page that exists but is linked from nowhere is hard for a visitor, and a crawler, to ever find. Brief where it should be linked from, not just the page itself. See Being found.

• A word changed in one place, and not the other three

  Owner: You

  The same price or the same name printed on more than one page drifts the moment only one copy is updated. Brief every place a word appears, not just the one you noticed. See Brief a change.

• A change went live before you saw it

  Owner: You

  Merging a pull request is the step that ships it, not opening one. Click the staging link first, the same way any other change gets checked before it merges. See Review.

• No admin screen to log into

  A static build has no dashboard, no login, and no button that edits a live page. Every word or picture ships as a briefed pull request instead.

• No keyword research or content strategy

  Choosing what to write about, and which words to use, is your call. We keep the technical side clear; we do not plan your content.

• Nothing merges itself

  There is no setting that lets an agent merge its own pull request. A person approves every change, including when you would prefer that it did not.

• A redesign

  Changing the visual system before there is anything to react to needs a plan, not a diff. Start that as a build with CustomLabs, then bring the iterations here.