Inspect the current site
We begin with what is already there: the website, its code, connected accounts and the jobs it needs to do. For HTSG, that meant public product pages, a private portfolio register, project inquiries and regional brands with different release histories.
Before changing anything, we identify the working forms and connections that need to survive the update. AI helps us inspect and organize the material. We still have to decide the scope and record which sites are actually being changed.
Describe what people need to do
We describe the task through things a person should be able to do: find a product, understand the offer and send an inquiry with the relevant details. The page must work on a phone, and the team must be able to retrieve the inquiry.
Content research, interface design and integration review can happen alongside one another. They still need shared decisions and a person responsible for what the business promises and releases.
Read it, try it and revise it
Generated copy and interfaces are drafts. We read the pages, try the controls and ask whether the words and visuals help a customer. A layout can load correctly and still feel generic, sparse or difficult to use.
The earlier headquarters foundation included checks across 25 public routes, isolated inquiry tests and a labeled live inquiry confirmed in the business inbox. That gave us evidence that key functions worked. The design still needed attention, leading to this broader review of the presentation and product pages.
Keep a record of the release
We keep the source, test notes and a recovery path with each release. The record should identify unfinished connections and distinguish a headquarters update from work deployed to a regional site.
OpenAI describes Codex as a coding agent for development work. Our use of it does not imply an OpenAI endorsement of HTSG. We record which tools were used and what the tests demonstrated, so the account remains useful as the tools change.
