HearthHome Care Agency Landing Page

Hearth is a landing page for a home care agency, built around the family who lands on it: usually stressed, usually on a phone. It explains services, answers common questions, keeps a call button in reach, and turns a visit into a callback request. It is skinned as a fictional agency (Maple & Main Home Care, Charlotte NC), and every name, number, review, and statistic on it is a placeholder.

The page renders on the client, so crawlers that do not run JavaScript would miss the content and structured data. The staff inbox at #inbox keeps leads in the visitor's own browser, which is a demo convenience and not where a real agency should keep family contact details. No real CRM endpoint was wired up. It was built to show what is possible, not polished for a live client.

This came out of the September 19 one-shot night, one of the parallel Claude Code builders working off the shared brief. I directed the scope: a revenue-track page for a niche I know, config-driven so I could re-skin it for a paying client in an afternoon, with a real lead path instead of a dead form, and honest placeholder data for things like the license number and reviews.

Claude Code wrote site.js, the page, the 133 assertions, and the server. Everything on the page renders from one SITE object: copy, palette, services, plans, towns, FAQs, form options. The first session got interrupted after the app, tests, and screenshots were done but before the write-up. A second session re-ran the tests, re-checked both themes, and wrote the docs without rebuilding anything. Logged time was about half an hour.

• Generate the JSON-LD from the same config as the visible page. When the service area, the offer list, and the FAQ markup come from the same arrays that render the sections, a client edit updates both, and there is no second copy to forget.
• A honeypot should fail quietly. If a bot fills the hidden field, it gets the normal thank-you and nothing is stored or posted, so it has no signal to adapt to.
• A flat map at city scale needs longitude scaled by the cosine of the hub latitude. Without it, towns east and west of Charlotte landed about 20 percent too far out and sat outside a radius ring the distance math said they were inside.
• A form with no backend still needs a lead path. Saving to localStorage plus a prefilled email means the demo works end to end, and pointing it at a real CRM is one data-endpoint attribute.
• Close town labels collide (Cornelius and Davidson). A greedy placer that tries eight positions per town fixed it.

Same backbone as the rest of the sprint: a DOM-free core module that both the page and verify.mjs import, which is the pattern that started with #9 through #11, plus the zero-dependency serve.mjs on port 5122. The test suite even checks WCAG contrast on both palettes. Project #24 went after the same home care niche from a different angle, a survey readiness checklist, so the two read as a pair even though they share no code.

I would pre-render the HTML from the config at publish time so the content and JSON-LD sit in the static source, and keep client-side code only for the form. Then I would move the inbox behind the endpoint where lead data belongs.