Rebuild an AI Website Without Losing Approved Decisions

Reviewed by Product Specialist at thinQit. Updated 4 November 2026.

To rebuild an AI website without losing approved decisions, write the decisions down as a fixed record first, rebuild around that record, and check the new build against it before anything goes live. thinQit, the AI delivery workspace from thinQit B.V., keeps that record in shared project context so a rebuild starts from what was signed off.

A rebuild is the riskiest moment for an AI-built site. The new build is fast and fluent, so it can look finished while quietly dropping a navigation rule, a wording choice or a legal line that someone approved weeks earlier. The method below keeps those decisions intact. It works for a full rebuild and for a large redesign of one section.

Why do approved decisions get lost in an AI website rebuild?

Approved decisions get lost because an AI builder only knows what is in front of it. If a decision lives in a chat thread, a meeting or one person's memory, the rebuild cannot see it and will fill the gap with a plausible default. The result looks consistent and is wrong in small ways.

Three patterns repeat. First, decisions are stored as conversation, such as "we agreed the pricing page leads with the plans". Second, the reason is missing, so a later change cannot tell a deliberate choice from an accident. Third, nobody can check the decision, because it was never written as something observable. A rule like "keep it simple" cannot be verified. A rule like "the pricing page shows plans before any feature list" can.

The boundary: a decision that was never approved is not at risk, because there is nothing to lose. The effort belongs on the choices a named person signed off, since those are the ones the business will notice when they vanish.

What counts as an approved decision on a website?

An approved decision is a choice that a named person agreed to and that changes what a visitor sees or what the build must do. It is narrower than a preference and broader than a requirement. If reversing it would need someone to say yes again, it belongs in the record.

Typical examples on an AI-built site:

• Structure: which pages exist, what the navigation shows and in what order.
• Wording: the product names, the claims the business is willing to make and the phrases it avoids.
• Behavior: what a form submits, where it sends people and what happens on an error.
• Constraints: pages that must not change, integrations that must stay, and areas another team owns.
• Approvals: who signs off on a release and what evidence they need.

Keep ideas and open questions out of this list. Mixing them in dilutes the record, and a reviewer will stop trusting it.

How do you capture decisions before you rebuild?

Capture decisions in one shared place, in a fixed format, before the rebuild begins. Each entry needs four fields: the decision, the person who approved it, the reason, and the check that proves it holds. The fourth field is the one teams skip, and it is the one that makes the rebuild verifiable.

A practical entry looks like this:

1. 1Decision: the pricing page shows plans before any feature list.
2. 2Approved by: the product owner, on the date of the sign-off.
3. 3Reason: visitors arrive from the pricing link wanting a price first.
4. 4Check: open the pricing page and confirm the plans block is the first content section.

In thinQit, the Codex website and app builder works from project context that holds decisions, constraints and earlier findings, so the build and the reviewer judge a change against the same facts. The idea is described in more detail in our piece on how Compass makes project knowledge reusable. If your decisions currently live in chat, move them into that kind of shared record first, then start the rebuild.

Mark what is frozen and what is free

Label each entry as frozen or free. Frozen means the rebuild must preserve it exactly. Free means the rebuild may improve it within stated limits, such as layout details that were never approved. This one label stops two failure modes: a rebuild that changes everything, and a rebuild so cautious that it changes nothing.

How should you structure the rebuild itself?

Structure the rebuild as a series of small slices, each tied to a group of decisions, and review each slice before starting the next. A slice might be the navigation and page structure, then the pricing page, then the forms. Small slices keep the comparison against the record cheap and the damage from a mistake contained.

For each slice, hand the AI builder the relevant frozen decisions along with the request. The builder then has the constraint in front of it instead of guessing. Our walkthrough of an AI web app build from discovery to iteration shows how discovery output feeds the build, and the same pattern applies to a rebuild: what was decided in discovery stays an input at every later stage.

Order the slices by risk. Start with the decisions that are expensive to reverse, such as structure and anything legal, and leave visual polish for last. A structural mistake discovered at the end forces rework on every slice built after it.

How do you check the new build against the record?

Check the new build by walking the record entry by entry and running each entry's check against the rebuilt site. A pass means the check holds. A fail means either the build is wrong or the decision has changed, and those two cases must be told apart before anyone fixes anything.

Use a short review pass for each slice:

1. 1Read the entry. What exactly was approved?
2. 2Run the check. Look at the rebuilt page, not at the builder's summary of it.
3. 3Record the result. Held, broken or deliberately changed.
4. 4Route a break. A broken decision goes back to the builder. A deliberately changed one goes to its approver.

This is the same discipline we describe for AI pull requests: judge the result against the request, not against how plausible it looks. Our guide to AI-generated code review covers the habit in detail, including why a tidy output is not evidence that it is correct.

Look for what went missing

The most damaging losses are absences. A rebuilt page can be complete and attractive while missing a disclaimer, a redirect or a form field that existed before. Compare the old and new structure side by side for each page and ask what is no longer there. An item that vanished with nobody deciding to remove it is a lost decision.

What happens when a decision needs to change during the rebuild?

When a decision needs to change, treat it as a new approval: stop, name the decision, state the reason, and send it to the person who approved the original. The rebuild continues on the other slices while that question is open. The change is applied only after a yes, and the record is updated in the same step.

This is where approval gates earn their place. Our explanation of how approval gates make AI delivery safer describes holding a change until the right person has seen the evidence. A rebuild is a good use of that pattern, because it creates many small opportunities to change something by accident. For wording choices that need sign-off, an AI project canvas for website approvals gives reviewers one place to see what was proposed and what was agreed.

The boundary: a change that only affects a free item does not need a new approval. Rely on the frozen and free label from the capture step, and when the label is unclear, treat the item as frozen until someone says otherwise.

How do you keep the record useful after the rebuild?

Update the record at the end of the rebuild so it describes the site as it now stands: which decisions held, which changed and who approved each change. Without that step the record drifts, and the next rebuild repeats the same loss in a new place.

Three habits keep it alive:

• Add the decision to the record at the moment it is approved, not weeks later.
• Remove entries that were superseded, and keep a one-line note of what replaced them.
• Have every AI teammate that touches the site read the same record, so nobody works from a private copy. The thinQit AI teammates are built to work from shared context for this reason.

A short record that people trust beats a long one that nobody opens. If entries stop being checked, prune them or fix their checks, because a record that is always out of date teaches the team to ignore it.

When is a full rebuild the wrong choice?

A full rebuild is the wrong choice when the problem is limited to a few pages or one behavior. Rebuilding everything puts every approved decision at risk to fix something small. Change the affected slice, run the checks for the decisions that touch it, and leave the rest alone.

A rebuild makes sense when the structure itself no longer fits the business, when the foundation blocks changes you need, or when decisions are already so scattered that the old build cannot be trusted. Even then, the record comes first. A rebuild without one is a new project that happens to look like the old one.

Security-relevant areas deserve extra care in either case. Credentials, permissions and anything touching customer data should be marked frozen, and our guide to security guardrails for AI agents shipping production code explains which boundaries an AI builder should never cross quietly.

Curious what it costs?

See the pricing and pick what fits you.

See pricing