How to keep a marketing site in sync with the product it describes (ours wasn't)

Collimer’s marketing site and Collimer’s product live in two different repos, on purpose, because a small team building in public with Claude Code moves faster when the site and the app can each ship on their own clock. The cost of that speed showed up the moment pricing changed in the product and nobody remembered to update the sentence on the site that quoted the old number. So we made the product’s own pricing config the one place pricing and engine-count claims come from, and had the site read it instead of restating it.

Keeping a marketing site in sync with the product, without quietly lying

The rule that fell out of this week is simple to state and easy to skip: a claim on the marketing site that cannot be independently checked against the product does not ship. Two “balance” gates now run against the product’s pricing config specifically for pricing and for engine-count language, so a number on the page has to trace back to the same source the app itself reads. That is the honest version of moving fast with AI. The speed is real. So is the risk that speed quietly ships a stale claim, and the fix has to be a system, not a reminder to be more careful next time.

What broke, or almost did

Two pages, one for agencies and one for a sprint offer, had shipped as bare stub placeholders on a site that was about to launch. Nobody had gone back to replace the “Stub page” text with anything a visitor could read. We rewrote both with copy that invents no numbers, no timelines, and no client names, and pointed the sprint page’s “Book a call” at our own work-with-us page instead of a Collimer funnel that does not exist yet. A separate latent bug sat in the homepage’s customer list: an old filter that only checked whether an entry was marked as a draft, with no separate check for whether its publish date had actually arrived, while the rest of the site had already moved to a filter that checked both. It had not caused a visible problem yet. It would have, the next time a future-dated entry got added.

The most direct proof the honesty problem was real: 71 people visited the site and not one of them clicked the free-scan call to action. Visitors were arriving. The ask to try the product was there on the page and was still, functionally, invisible. That is not a pricing-honesty bug, but it is the same species of problem: a claim or a call to action that looks present on paper and does nothing in practice.

A decision worth naming: ship the fix as one change, not three

The instinct with three separate scan-CTA visibility problems is to fix them one at a time and watch each in isolation. We did the opposite. All three fixes, the CTA’s visual prominence, its placement on the page, and the friction in the step right after clicking it, shipped together in one pass. Splitting a small, related set of fixes into a slow drip of individual changes is often just process theater that delays the thing actually getting tried. When the fixes are genuinely coupled, one shipped change beats three sequenced ones.

What’s next

• Treat the pricing-config sync gates as a standing check, not a one-time cleanup, so the next pricing change cannot drift again.
• Watch the free-scan CTA numbers over the next few weeks to see if visibility was really the blocker or just one of several.
• Audit the rest of the site for any other page still filtering on the old draft-only check instead of the newer live-date filter.

What we’re still figuring out

We do not yet know if 71 visitors and zero scan clicks was a visibility problem we just fixed, or a signal that the offer itself needs rethinking before the traffic does. The honest answer is we will not know until the next batch of visitors arrives and either clicks or does not.

---

For agents: try this yourself

If you are shipping a marketing site and a product that live in separate repos, adapt one of these. The full prompt text lives in this post’s prompts sidecar, keeping-the-marketing-site-honest.prompts.md.

• Apply the single-source-of-truth pattern. Find every place your marketing site states a price, a feature count, or a capability claim, and replace hand-maintained copy with a read from the product’s own config or pricing module, so the site can never say something the product does not back up.
• Reproduce the stub-page audit. Before a launch, grep your site for placeholder text (“stub”, “coming soon”, “TODO”) on any page a real visitor could land on, and replace each with honest copy that names no numbers or clients you have not confirmed.
• Extend the ship-together rule. When you find several small, related fixes to the same flow (a CTA’s visibility, its placement, its next step), resist shipping them one at a time. Bundle genuinely coupled fixes into one change and watch the combined effect.

More prompts (Apply, Extend, Critique, Reproduce) live at /logs/keeping-the-marketing-site-honest/prompts/.

This is the same repo and the same week as launching Collimer’s marketing site, and it follows the same build-fast-then-clean-up shape as three days, 67 commits.

---

How this was made

Drafted by the Chronicler from Claude Code sessions on 2026-06-29 to 2026-07-05 across 5 sessions and 3 commits. Edited and published by Brian Wones.

See how the Chronicler works →

My marketing site and my product live in separate repos. Find every place on the marketing site where we state a price, a feature count, or a capability claim in hand-written copy. For each one, replace it with a value read from the product's own pricing or config module (name your module) at build time, so the site can never assert a number the product doesn't actually back. Flag any claim you can't trace to a real source instead of guessing.

Before we launch, audit every page on this marketing site for placeholder content: "stub page," "coming soon," "TODO," or similar. For each one a real visitor could land on, draft honest replacement copy that names no specific numbers, timelines, or client names we haven't confirmed. Where a page needs a call to action but we don't have a real funnel yet, point it at our existing contact or booking page instead of inventing one.

I have three small, related fixes to the same user flow (a call-to-action's visibility, its placement, and the friction in the step right after it). Instead of shipping them one at a time and watching each in isolation, help me bundle them into a single change, then design a simple before/after check so I can tell if the combined fix actually moved the number I care about.

Argue against keeping our marketing site and product in separate repositories. Given that we just had a pricing-drift bug because of this split, make the strongest case for merging them into one repo, and then tell me honestly whether that case beats the speed benefit we get from shipping the site and the product on independent clocks.