Diamond Star Cleaning Services

The problem

A local services business needs the same facts to be identical in a dozen places at once — the Google Business Profile, the website, the schema markup, review requests, directory citations, and whatever an answer engine reads. Hand-writing a service page, then filling in the profile afterwards, guarantees the two disagree within a quarter. The usual failure is not a missing page; it is nineteen services and fifteen locations described three slightly different ways.

Approach

1. 01

   Built the business entity as a database first — one JSON catalog holding the services, locations, property types, tasks, trust attributes, hours, and the schema model — and treated it as the only place any of it is edited.

2. 02

   Specified the Google Business Profile from that catalog before writing a page, then built the site field-for-field against the specification rather than designing a site and retrofitting the profile.

3. 03

   Wrote a Python build that renders the site as a view of the catalog: pages, JSON-LD, internal links, and the sitemap all regenerate together, so a page cannot drift from the specification because no page is written by hand.

4. 04

   Derived the design system from the logo mark — a facet geometry, a serif no local competitor uses, and one accent held back far enough to read as metal — and wrote it down as a rule set the build is checked against.

5. 05

   Made the voice agent the contact path instead of a form, and built the SMS consent and terms pages the A2P 10DLC registration depends on before the campaign was submitted.

Outcome

The site ships as 38 static pages with no runtime dependency, and every fact on it traces to one record. Changing a service description in the catalog updates the page, its schema, the internal links, and the sitemap in one build.

Key decisions

1. 01

   A JSON catalog compiled by a Python build

   Instead of: A CMS, or a JavaScript framework with a headless backend

   The requirement was that no page could be edited independently of the specification. A CMS invites exactly that, and a framework would have added a runtime and a build toolchain to a site that is nineteen services and fifteen towns. The output is static HTML with no dependency to keep patched.

2. 02

   The Google Business Profile specified before the site was designed

   Instead of: Designing the site first and filling in the profile afterwards

   For a local business the profile is the entity Google actually ranks; the website is the expanded representation of it. Built in the other order, the two disagree, and reconciling them later means rewriting whichever one lost.

3. 03

   A voice agent as the only contact path

   Instead of: A contact form

   Most of the traffic is mobile and wants to reach someone now. A form defers that to whenever the inbox is next opened, and the business already had a line that gets answered.

4. 04

   Gold barred from filling any button

   Instead of: Following the reference site's yellow call-to-action pattern

   The reference uses a far brighter yellow. At this brand's gold the same pattern fails contrast against white text and reads muddy against dark, so navy carries every call to action and the gold stays rare enough to read as a metal.

In short

Is this just a website for a cleaning company?

The website is one output of it. The project is a local entity model — a single machine-readable record of the business, its services, and its service area — that the Google Business Profile, the site's 38 pages, the schema markup, and the review and citation programme are all generated from or checked against. Building it that way is what keeps the same nineteen services described identically everywhere a customer or a search engine encounters them.