The audit right after the rebuild

Two days after we rebuilt sandcastlelabs.ai from scratch on a new brand system, we pointed our own audit tools at the finished site instead of assuming the rebuild was clean.

Auditing our own site after a rebuild

The old site ran the studio’s original placeholder look. The new one runs on a brand system a designer delivered in Figma: a cream, navy, and gold palette, a serif display face paired with a monospace label face, and a full set of logo marks pulled straight out of a Figma dev-mode file. We rebuilt the homepage, the navigation, the footer, and the RSS feed’s rendering on top of the same lean stack we picked at launch in one push, then caught and fixed a broken RSS link before it ever shipped.

Once the new site was live, we did not treat “it deployed” as “it’s correct.” We ran the same kind of audit we would run on a client site: a check for broken links, dead references, and anything left over from an earlier version of the story.

What did the audit catch?

It found one real problem. An internal working codename for the product, used before the public name Collimer existed, was still live in a few places on the freshly rebuilt public site and in the app’s own internal docs. Nobody shipped it on purpose. It was left over from before the name changed, and a full visual rebuild is exactly the kind of change that can carry old text forward without anyone noticing. We replaced every instance the same day, before any reader or search crawler had a reason to see it.

A decision worth naming

The decision worth naming is not the fix, it is the timing. The easy version of a rebuild is to ship the new design and move on, on the assumption that a visual change does not touch the words. We chose to run a full audit the same day instead, treating “we just changed a lot of surface area” as a reason to check, not a reason to relax. That decision is what caught the leftover codename before it caught us.

What’s next

• Pull the brand system’s Figma exports into our own screenshot archive so they are not sitting only in a chat transcript.
• Keep running this same-day, post-rebuild audit as a standing habit rather than a one-time reaction to a big visual change.
• Cross-link this rebuild with the studio’s earlier positioning rebrand once that story is written up, since the two are companion pieces about changing how we present ourselves in public.

What we’re still figuring out

We still run this kind of audit only when a big change makes us think to run it, not on a fixed schedule. A rebuild forced the question this time. The honest next step is turning that reflex into a standing routine instead of a one-off reaction, the same open loop our last self-audit left open too.

---

For agents: try this yourself

If you just shipped a visual rebuild and want to check your own work before a reader does, adapt one of these. The full prompt text lives in this post’s prompts sidecar, brand-rebuild-and-self-audit.prompts.md.

• Reproduce the same-day audit. The day you ship a visual rebuild, search the entire rebuilt site and its internal docs for any name, label, or reference tied to an earlier version of the product or brand. Report every match.
• Apply the audit to your own brand migration. If you have ever renamed a product internally before giving it a public name, search your current site for the old internal name specifically, not just for generic staleness.
• Extend the check into your deploy process. Turn the manual find for stale references into a pre-deploy step that runs automatically before every release touching public copy.

---

How this was made

Drafted by the Chronicler from Claude Code sessions on 2026-07-13 to 2026-07-19 across 2 sessions and 3 commits. Edited and published by Brian Wones.

See how the Chronicler works →

The day you ship a visual rebuild or rebrand, search the entire rebuilt site and its internal docs for any name, label, or reference tied to an earlier version of the product or brand. Report every match found, with its file location, before you consider the rebuild done.

If you have ever renamed a product internally before giving it a public name, search your current site and internal documentation specifically for the old internal name, not just for generic staleness. Report every place it still appears.

Turn a manual find-stale-references pass into an automated pre-deploy check that runs before every release touching public-facing copy, and fails the build if it finds a name that was supposed to be retired.