A website becomes much more useful once you can operate it without being trapped inside the system that originally published it. This guide is about Should an Agency Deliver Client Sites in Framer or Code. The goal is not to make the process sound easier than it is; it is to show the concrete decisions, files, checks, and trade-offs involved in platform migration and AI-assisted reconstruction.
A useful distinction comes first: a public website is evidence of its accessible presentation and behavior, not a complete specification of every private system behind it. A reconstruction can cover pages, routes, visible content, assets, layout relationships, typography, responsive behavior, links, and some visible interactions, while private databases, authentication, server logic, secrets, proprietary CMS data, and account-level integrations may need separate work.
What this actually involves
The central decision is whether you are comparing two tools, leaving a platform, or reconstructing an accessible experience. Those are different jobs. Framer may provide a visual editor, managed hosting, CMS features, collaboration, or platform-specific interactions; an AI coding agent works on files and code. An owned codebase gives you different control, but it also gives you responsibility for deployment, updates, backups, debugging, and any services that the builder previously managed.
If reconstruction is involved, evaluate the result against evidence rather than intuition: compare representative desktop and mobile views, routes, typography, spacing, assets, navigation, hover/focus states, animations, forms, and SEO behavior. Then inspect the code for maintainability. A visually close page built from an unmaintainable pile of duplicated markup is not the same outcome as a clean, testable codebase.
Step 1: Establish the baseline
Before editing or migrating, preserve the current state. Record the important URLs, take representative screenshots, note the framework and deployment method if known, and make a backup or Git commit. For a platform move, also inventory domains, redirects, forms, analytics, search metadata, important assets, and third-party services. This baseline prevents a common migration mistake: discovering after launch that a small-looking change quietly removed an important page or behavior.
Step 2: Identify what is truly transferable
Separate public presentation from private infrastructure. Accessible pages and assets can often be studied or reconstructed. Private APIs, databases, login systems, server-side rules, payment systems, email delivery, analytics accounts, and proprietary CMS workflows are different dependencies. Make a table for the project with three columns: reproduce, reconnect, and rebuild. Put each requirement in one column before assuming the move is complete.
Step 3: Do the work in a controlled environment
For code changes, work locally or in a preview deployment rather than directly against production. Keep changes small and descriptive. Run the project’s documented install and build commands. If a command fails, read the first meaningful error instead of repeatedly reinstalling packages. For a visual comparison, use the same viewport dimensions and representative pages; otherwise you can mistake a viewport difference for a reconstruction error.
Step 4: Verify the user experience
Test more than the homepage. Check a deep route, navigation, images, typography, buttons, forms where applicable, responsive behavior, and any visible animation or interaction that matters to the site. Test keyboard focus and obvious accessibility paths when the change affects interactive elements. A migration should be judged by user journeys and important URLs, not merely by whether the deployment dashboard reports success.
Step 5: Make ownership explicit
Keep the domain and billing accounts under the owner’s control. Store the repository in an account or organization the owner can access. Document the hosting provider, deployment command, environment-variable names, third-party services, and maintenance responsibility without publishing secret values. If a developer leaves, another developer should be able to understand how the site is built and deployed without needing someone’s personal laptop or password.
Practical checklist
- Back up the current project.
- Record important URLs and user journeys.
- Identify the framework and build process.
- Find the source of truth before editing.
- Separate public presentation from private backend dependencies.
- Make a small change or migration step.
- Run a local build or preview deployment.
- Test desktop and mobile.
- Test deep links, assets, forms, and interactions relevant to the change.
- Review the Git diff before publishing.
- Verify the real production URL after deployment.
- Document what changed and how to reverse it.
Common mistakes
The most common mistake is treating the task as a single switch. A site has several layers: code, content, assets, URLs, hosting, DNS, search configuration, integrations, and private application logic. Another mistake is optimizing for a screenshot while ignoring routing, keyboard behavior, loading states, or maintainability. A third is changing DNS before the new deployment has been tested. Finally, avoid putting secrets into repositories or assuming that a public page gives you legitimate access to private systems behind it.
Where PortCode fits
PortCode is positioned as a website reconstruction and platform-exit tool: it helps turn an existing website or authorized public reference into a project you can own, edit, deploy, and move. The beta is hands-on and asynchronous, and the result should be treated as a working codebase that still deserves review and testing. The point of ownership is not that every future task becomes effortless; it is that the website is no longer locked to one visual editor or hosting environment.
Final takeaway
The durable solution to Should an Agency Deliver Client Sites in Framer or Code is a repeatable operating process. Preserve a known-good version, identify the real source of truth, change one layer at a time, verify behavior rather than only appearance, and keep the domain, repository, and deployment access under the owner’s control. If you do that, platform migration and AI-assisted reconstruction becomes an engineering workflow you can understand and hand to someone else—not a one-time rescue operation.
FAQ
Do I need to understand every file first?
No. Understand the framework, build process, deployment path, and the files relevant to the task. Expand your understanding as the change touches more systems.
What if the result is not identical to the original?
Treat differences as individual test cases. Compare the same route, viewport, assets, typography, and interaction state. Fix the underlying cause instead of accumulating random CSS patches.
What about private functionality?
A public reconstruction does not automatically recover private databases, authentication, server code, secrets, or proprietary integrations. Those require authorized access and separate implementation or migration work.
Should I publish before testing?
Prefer a local build or preview deployment first. Production should be the last verification step, not the development environment.