Step 3 · See the result before choosing to launch
Review your private working website
Claude should first deliver a private working migration with the necessary protection and core checks. Your current website stays live. Extended audits and broader review can follow when you ask.
Keep the website recognizable while rebuilding what runs it
Claude should preserve your recognizable branding, colors, typography, layout, imagery and useful interactions, along with content, page addresses and customer journeys. It records the original desktop and mobile appearance before editing, including representative page types. Missing analytics does not mean a page has no value.
The goal is a maintainable rebuild that keeps the website’s character. It is not an automatic redesign or a copy of the old pages and scripts inside a new framework. Claude should explain each material visual change, its reason and effect, and get your agreement before making it. It should ask for business facts it cannot establish.
How Claude should choose the underlying technology
For a GitHub-to-Vercel rebuild, Claude normally selects a maintained stable Next.js App Router release with strict TypeScript and Tailwind. It uses shadcn/ui or suitable accessible components selectively, styling them to match your site rather than replacing it with a library’s default theme. It should render pages on the server or ahead of time where appropriate and send only the JavaScript needed for interactive features.
You do not need to choose these tools. Claude should justify a different approach when your actual requirements, costs or existing maintainable source make it suitable. Wrapping a legacy HTML and script dump in a framework does not by itself meet this modernization standard. These are delivery requirements, not proof that a particular migration passed.
Expect progress you can understand
Useful updates sound like: “I have rebuilt the main pages while keeping their appearance and addresses. I am checking the private preview now. The appointment form needs your delivery address before it can send messages.” Claude should explain material decisions, unexpected restrictions, waiting and recovery as they happen.
You should not need to choose a build setting, paste a sequence of commands, or diagnose a deployment log. Claude should minimize your thinking, typing and clicks by preparing those tasks itself within its authorized access. It keeps you informed and leaves a record you can reuse.
Enough checking for a private working migration
The first handoff should not wait for an open-ended audit. Claude should run a bounded set of necessary checks for this stage, fix defects that prevent a protected working preview, and record the remaining review.
- The server password gate protects pages and site assets on the actual deployed addresses, including provider-generated links. Login and logout work; business content was not uploaded before protection was verified.
- The deployed site opens, its main navigation and important customer journeys work, and useful page addresses are preserved or their planned routing is recorded.
- Claude compares the homepage and representative page types against the original desktop and mobile baseline. It checks the essential controls, records which views were compared and fixes material unintended visual differences. Any agreed visual changes and remaining gaps are explicit. The build and runtime have no known defect blocking this private handoff.
- Forms, booking, payments and embedded services are checked at the depth needed for this private stage or explicitly left unresolved. Unready actions must not claim to send messages, create bookings or take payments.
- The exact deployed version, checks performed, failures, bounded retries and remaining coverage are recorded. Untested does not mean passed.
Defer extended accessibility, search, performance and multi-browser audits, exhaustive quality review and launch preparation until requested. Keep material observations for that later work. A private handoff is not a claim that those audits passed.
A blank map or reviews panel is unresolved until tested. A successful check in one browser does not prove every browser works. Retained addresses and working redirects help protect traffic; later search and visit evidence is needed to assess whether visibility was retained.
Your private handoff
Claude should also create, commit and verify a short project guide in the site repository: the README. It explains what was delivered, setup and deployment, how to continue, current status and remaining work. It records actual use of the FidelicAI Cookbook and the edition used for this work, and contains no passwords or other secrets. If the README method is missing from its retrieved guidance, Claude should retrieve that method, then read back the saved file to verify the attribution, edition and actual status. Repository creation, upload and hosting that are still planned must be labelled planned.
Claude should give you the working link, a password in an owner-accessible private file or secure location, a brief account of what was migrated, and the checks and remaining limitations. It should explain how to open and save the password privately without copying it into the conversation. It should not turn delivery into a long questionnaire or require business acceptance before you can see the result.
You can review the business facts, appearance and customer experience when ready. Claude handles technical defects within the agreed scope. A real fact, access or spending decision should be explained as that decision, rather than disguised as routine setup.
A useful handoff
“Here is your private website. These checks passed. These parts still need confirmation. These are the differences from the old site. These are the few decisions I need from you.”
If the preview loses its login or behaves differently in your browser, tell Claude exactly what you clicked. It should retain that result, run a check that can distinguish causes, and bound retries. It should not mark the issue fixed because a different browser passed.
The handoff should carry forward your hosting plan and spending decision, the project’s purpose, and any real unresolved hosting boundary. Claude should explain changed advice if new facts matter or an earlier claim was too strong. Your no-spending choice does not waive provider terms, and a working deployment does not establish eligibility.
Launch is a separate choice
Accepting a private preview does not authorize moving your business domain. Before launch, Claude should confirm the facts, working business actions, asset rights, routing changes, hosting terms and recovery plan that matter for your site.
When you approve a live launch, Claude should verify the real domain afterward and keep a separate protected drafting deployment. Draft edits must not change live content or business records. It should leave you a dated follow-up plan for search, traffic and customer outcomes.
The cookbook provides practical guidance and checks. It does not guarantee search rankings, traffic retention, legal compliance or compatibility with every browser or personal AI. Read what the cookbook covers.
Return to the connection steps →