How we use context-aware AI to design and build websites

AI-first means every step starts by giving the AI the context it needs. The AI world has a name for giving it that context: context engineering. Prompt engineering is about how you phrase the question. Context engineering is about what the AI can see when it answers: the documents, data and rules it works from. For a website build, that means the designs, the content, the facts and the SEO plan.

Most people use AI through a chat window. You ask a question, you get an answer, and the answer knows nothing about your project.

On a typical website project, the code repository holds code and nothing else. The SEO plan lives in a spreadsheet, the designs in a design tool, the copy in documents, and the facts in someone’s head. Developers switch between all of them, and things fall through the gaps.

So we put the context next to the code. Alongside the site itself, the project holds:

• A baseline of the old site. A full crawl of every live URL, used to plan and test redirects.

• The approved designs. Used for design QA at every screen size, from phone to wide desktop.

• Design system and brand guidelines. Colors, type, components and how the brand is used.

• Content and assets. The site’s current content and media, plus a backup of the old site.

• Docs. A facts and proof document (company details, key dates, partner status and the figures we’re allowed to use), the style guide and a content brief for each page.

• SEO. Meta titles and descriptions, H1s and target keywords for every page.

With that in place, the AI doesn’t work on code in isolation. Our developers decide what it checks, and point it at the technical details that matter most: redirects, structured data, performance budgets, accessibility and SEO. It can then check every page against the designs, the content, the facts and the SEO plan.

A small example shows why that matters. The date of an event can easily exist in two versions: 2025 in the page content and 2022 in the structured data. Nobody notices, because each version lives in a different place. With a facts document in the project, the conflict comes up during the build, and once the right date is confirmed, it’s corrected everywhere it appears.

Strategy and requirements. Before any design, we write the foundations: a strategy document, a tone document, a design brief built from sites we like and dislike, and technical requirements for hosting, stack, SEO, performance and browser support. AI helps with the research, and generates example copy for the key pages from those documents. We review and rewrite it, so design starts from real content.

Design. We feed the strategy, tone, brief and copy into an AI design tool, which generates a draft design system and an example site. With that much context, the first result is already a useful starting point: fonts that fit the brand references, accent colors, layout ideas. The draft is a complete brief that we share with the designer, who creates the design system from it, then designs and refines each page and component through a normal review process, from look and feel through to every page. Feedback changes too: instead of describing a change in words, the team can draft it and send a visual example to the designer.

Development. We pull the approved design into code, using AI to generate a first development build. It’s a strong starting point and nothing more: content is hardcoded, and it isn’t pixel perfect yet. Responsiveness, browser consistency, performance and technical SEO all still need work. This is where our developers take over: they build the Contentful content models so every page is editable, match the build to the designs at every screen size, and build out the features, all checked against the content briefs, the SEO plan and the facts.

When we rebuilt our own site with this workflow, the difference showed up in three ways.

Problems get caught before they ship. The crawl of the old site became the redirect test. It caught an old rule that sent some article links through two redirects, or to a page that didn’t exist. We replaced it with 10 simple rules.

The same checks caught a cookie-settings link that would have silently stopped working, and old copy in the CMS that would have quietly replaced the new text. And the backup of the old site showed that 249 old images were still linked from past emails, social posts and search results, so we kept them.

The numbers are measured against budgets. Because the performance budgets sit in the project, every audit runs against them. In local testing before launch, we found a 60KB bundle of chatbot content being sent to every browser. Removing it took mobile Lighthouse scores from a range of 56–94 to 90–95 across the pages measured, and blocking time from as much as 1.5 seconds to under 0.25 seconds. By launch, every page type scored 96–98 on mobile.

More gets done, and done properly. On one day of the build, we shipped more than 100 scripted content updates to the CMS, covering page briefs, case studies and blog metadata. Alt text for more than 100 images was written from the images themselves, then reviewed. Site-wide wording changes were reviewed one match at a time. The AI’s suggestions improve with context too. Given the strategy, the style guide and the SEO plan, they fit the project, and the AI can explain the trade-offs. Every suggestion is still tested: ideas that make pages heavier are measured and reverted, and fixes that land in the wrong place, such as the content instead of the layout, are redone properly. The evidence decides, and people make the call.

For the brands we work with, this workflow shows up where it matters most:

• Earlier feedback. Draft designs and copy appear in the first weeks, so decisions are made on something you can see rather than a spec, and each round of feedback is quicker to act on.

• Safer migrations. Every old URL is crawled, mapped and tested before launch, so rankings and inbound links aren’t lost to broken redirects.

• Accurate content. Figures, dates, partner claims and testimonials are checked against an agreed source, not copied from wherever they last appeared.

• Consistent voice. The style guide and tone documents shape every page, so copy stays consistent across dozens of pages, and in features like a chatbot.

• Fewer surprises at launch. Design, content and SEO issues are caught during the build, so final QA confirms quality rather than discovering problems.

• Checks that keep running after launch. Later changes are checked against the same context, so a new page or a quick fix is far less likely to break redirects, SEO or the facts.

• Context that stays with the project. Facts, decisions and rules sit in documents next to the code, not in one person’s head. When someone joins the project, or your team takes over later, the context is already there.

• Context your team can read. The documents are in plain language, so marketing and leadership can see and challenge the rules behind the site, not just the developers.

• Senior time on decisions. Less of our developers’ time goes into repetitive checks, and more into architecture, trade-offs and your roadmap.

None of this runs on autopilot. We make the calls at every step: the strategy, the tone, the design direction, what the designer refines, what ships and what doesn’t.

The biggest of those decisions are technical design and architecture: how to approach a problem, and which solution will scale and give people a good experience.

Our site’s chatbot is an example. The AI holds the conversation, and the site answers with cards built from real CMS content, such as a case study or a call booking. The AI chooses which card to show but never writes what’s on it, so it can’t invent a project or a person. We designed when each card appears and how booking a call works without leaving the conversation.

Leading the AI sometimes means overruling the plan, or its first answer. SEO recommendations get adjusted when they don’t read well, and every claim is checked against the evidence: where the published work doesn’t support a figure, the figure changes.

Context makes the AI propose better options. Experience decides which ones are right. Together, the AI brings breadth and consistency, and our developers and the designer bring the judgment to know when something that passes every check still isn’t right.

You can see the same pattern well beyond web development. A music tool like Suno gives far better results when you give it lyrics, a style and a reference to build from. A support chatbot that knows your order history is useful, and a generic one isn’t. A new developer joining a team does their best work once they’ve read the docs and the codebase. In each case, the capability is the same. The context is what makes it good.

I’m excited to see how context makes the apps and tools we use every day feel a little more magical. For now, the lesson for us is simple: the better the context you give your tools, the better the options they give you back, and the more time your team has for the decisions that matter.

If you’re planning a rebuild, a replatform or a migration and want to talk through how this workflow would apply to your project, book a call.