When to move from a website builder to custom code, and how to do it safely
Move when a feature your business depends on can't be built within the builder's limits, not when you're bored of it or a developer says code is better. Real signals are things like customer accounts, data the site must look up, or logic the builder can't express. When you do move, map every URL first, redirect each old address, and keep the old site running until the new one is checked.
Signals that are real
Deciding when to move from a website builder to custom code starts with the feature you can't build, not with the tool.
- People need their own accounts: a members' area, customer order history, client logins with their own files.
- The site must look things up: live stock, availability across several staff, prices from your own system.
- Your process doesn't fit the built-in forms: multi-step applications, file uploads, conditional questions, or rules that depend on text and dates.
- You need an integration the builder can't make, and no webhook or connector route covers it.
- Several people or systems write to the site's data and you need roles, an audit trail and tests.
- You keep paying for workarounds (three outside tools stitched together) that cost more in time and fees than a developer would.
Signals that usually aren't
- "It doesn't look unique." That's usually a design and content problem, solvable inside most builders.
- "Custom code ranks better." Search engines read the HTML they receive. Clear pages and good content matter far more than how they were made.
- "It's slow." Check images and third-party widgets first; Core Web Vitals explained shows where the time goes.
- "We might need it one day." Move when the need is concrete. Running code you don't need is a cost every month.
What changes when you own the code
| Website builder | Custom code | |
|---|---|---|
| Hosting, certificates, backups | Included | Yours to set up and check |
| Security updates | The builder's job | Yours: dependencies, framework, server |
| Changes to text | Anyone on the team | Often a developer, unless you add a content system |
| New features | Only what the builder offers | Anything you can pay to build |
| Monthly cost | A plan fee | Hosting, database, email, and developer time |
Plan the move
- Write down the one or two features forcing the move, and check once more whether a webhook, a form function or an outside service could cover them.
- Export what you can rather than starting from nothing. A builder that exports code saves weeks of rebuilding layout and copy.
- List every live URL from the sitemap, analytics and Search Console, including pages that get links from other sites.
- Build and test the new site on a temporary address. Check forms, emails, sign-in and every page on a phone.
- Map old URLs to new ones and set permanent redirects where the paths change. 301 vs 302 redirects covers which to use and for how long.
- Switch the domain's DNS to the new host at a quiet time, with a short TTL set a day earlier so the change spreads quickly.
- Watch Search Console and your inbox for two weeks: crawl errors, missing pages, forms that stopped arriving.
- Keep the old site's export as a backup, and only cancel the old plan once nothing points at it.
From Anticode to code
Anticode's limits are stated plainly, which makes the signals easy to spot. Published design-engine sites have no visitor accounts or member areas, no shopping cart or checkout beyond payment links, no inventory, shipping or tax handling, no file uploads on forms, no embeds and no video, no comments or scheduling for posts, and booking without deposits, calendar sync or staff rotas. Apps can't use a server-side database, live third-party data or multiplayer.
When you hit one of those, export the site as a standard Next.js project with TypeScript, Postgres through Prisma, server routes for bookings, contact, newsletter and email sign-in, customer and staff roles, and an admin area with two-factor sign-in. It has no Anticode runtime. Push it to GitHub, add the feature you need, then deploy it. Your domain stays yours: point it at the new host when you're ready. Anticode has no per-site redirect manager, so set redirects for any changed paths on the new host once the domain points there; a site on a name.anticode.dev address can't redirect elsewhere, so update every link to it. The developer handoff workflow covers briefing someone to take it on.
Mistakes that lose traffic or data
- Changing URLs without redirects, so links and search results lead to errors.
- Forgetting form data and subscribers held in the old system. Export submissions and lists before you switch.
- Rebuilding the design from memory and losing details customers relied on, such as opening hours on the home page.
- Moving with no one lined up to maintain the code. Custom code without an owner ages quickly.
Limits
No checklist decides this for you; the cost of a developer and your appetite for running software matter as much as features. A middle path is common: keep the marketing pages on a builder and run the one dynamic feature as a separate app on a subdomain.
Questions people ask
Will I lose my Google rankings if I move to custom code?
Not if every important URL either stays the same or redirects permanently to its replacement, and the content stays as good. Expect a short settling period.
Should I export or rebuild?
Export if the builder produces code you can work with. It keeps your copy, layout and structure, and lets a developer start from something real.
Can I go back to a builder later?
Usually by rebuilding the pages there. Keep the URL map from your first move; you'll need it again.