Guidance
Your workspace opens, the audit runs on your site, and the technical and editorial action plans are generated. You apply them, Iris answers when you get stuck. The team does not touch the site.
The method
A rebuild is not something you discover at the end. Here is the real order of the stages, what you sign off at each one, and what happens once the site is live.
Short answer
An engagement with a rebuild starts with a written scope, continues with designs submitted to your corrections, then the build and an acceptance pass on a private link before anything goes live. You sign off the scope, the designs and the acceptance pass. The switch only happens once those three agreements are given — and optimisation continues throughout the engagement.
The sequence
Every stage produces something written or visible. None of them rests on a verbal promise to be checked later.
A scoping workshop: what the site must do, who it speaks to, which pages matter, what content already exists, which technical constraints apply (booking tool, catalogue, existing integrations). It produces a written scope and a site structure.
Visual direction first, on the screens that carry the decision — home page and a typical page. You comment on them. The other pages are only designed once that direction is signed off: correcting an intention costs less than correcting twenty screens.
Your feedback is grouped into rounds, not handled as it arrives. A round closes with a version announced as such, which avoids the endless back-and-forth where nobody knows which design is authoritative.
The site is built on the platform chosen at scoping (WordPress or Shopify), content is migrated, and redirects from the old addresses are prepared. This is where retained visibility is decided: a rebuild that forgets its redirects loses the positions it had.
The site is reviewed together on a private link, before anything goes live: content, forms, mobile rendering, checkout flow where there is one. Corrections are made on that version, never on the public site.
The switch happens on a date chosen with you. Redirects ship at the same time, Search Console and Analytics are connected, and the workshop runs an audit on the new site so there is a measured starting point.
Review rounds
A rebuild project rarely derails on design. It derails on corrections: ten messages spread over three weeks, two versions circulating in parallel, and nobody knows which one is right any more.
So your feedback is grouped. You review a complete version, you gather your remarks, we deliver the next version. Every round has a before and an after, and what was signed off in the previous round is not reopened silently.
This is not about limiting your requests: it is about a request being taken into account once, completely, rather than three times by halves.
Without a rebuild
The two other plans skip the design stage. The sequence is shorter, and the audit is the starting point in both cases.
Your workspace opens, the audit runs on your site, and the technical and editorial action plans are generated. You apply them, Iris answers when you get stuck. The team does not touch the site.
Same start, but the team takes the fixes on, on your current site. Each batch is submitted for your approval before it goes to production — you keep your CMS, your host and your credentials.
Existing content is migrated and reworked for SEO. What is missing is written from the workshop’s editorial action plans, then submitted for your review: you know your trade better than we do.
Start from a finding
The free audit runs on your address and returns a score, the problems ranked by severity and the pages involved. That document is what the conversation is built on.