Builders are rented, not owned
You pay to use the platform, inside its rules. Your page content may export, but the design and add-on features often stay behind. Check what yours lets you take.

Stay on a website builder while your site is a brochure: a few pages, a contact form and content your team updates now and then. Move to a custom-built website when the site has to do work the platform won't allow, like connecting to your systems, carrying a brand the layouts can't hold, or giving you control over search.
The builder is rarely the problem. The ceiling is, and the cost of hitting it shows up as workarounds, lost enquiries and a site your team has stopped trusting.
You pay to use the platform, inside its rules. Your page content may export, but the design and add-on features often stay behind. Check what yours lets you take.
Workarounds, add-ons stacked on add-ons and features you can't build tell you you've outgrown the platform. The age of the site doesn't.
A builder doesn't sink your SEO by itself. Losing control of URLs, markup, speed and rendering does, and that control is what a custom build gives back.
Moving off a builder changes your URLs. Every old address needs a permanent redirect, or the rankings it earned don't come with you.
If your site is a brochure your team edits and it brings in the enquiries it should, stay on the builder. If it has to connect to your systems, carry a premium brand or give you full control of search, a custom build is worth scoping.
A website builder is a subscription platform: you pick a layout, drag in your content and the company hosts it for you, inside its rules. A custom website is built for one business from the ground up, with its own structure, code and integrations. The builder trades control for speed. The custom build trades speed for control.
| Factor | Website builder | Custom website |
|---|---|---|
| Starting point | A layout designed for many businesses | A structure scoped to your brand and audience |
| Getting online | Quick, once you've picked a layout | Scoping, design and a build before launch |
| Design | Within what the layouts and settings allow | Whatever your brand calls for |
| Features | What the platform and its add-on market offer | Built around your process and connected to your systems |
| Search control | The URL, markup and speed settings the platform exposes | Full control of URLs, redirects, markup, rendering and speed |
| Editing | The platform's editor, built for everyone | An editing setup built around what your team actually changes |
| Ownership | You rent the platform; what exports is up to the vendor | Code, content and accounts can be yours, if the contract says so |
| Cost pattern | A subscription, plus paid add-ons | The build, plus hosting and ongoing maintenance |
| Main risk | Hitting the ceiling after the business depends on the site | A build with no plan for who maintains it |
When the site is a brochure and it's doing its job. A few pages, a contact form, content your team updates now and then, and enquiries arriving at the rate you need: a builder handles that well, and a custom build wouldn't earn its cost. The question isn't whether builders are good. It's whether yours has become a limit.
A builder also makes sense early, while the business is still proving what it sells and to whom. Building custom around a business that's still changing shape locks in decisions you'll want to undo.
I'll say it plainly, because it's not what you'd expect from someone who builds custom: if your builder site is doing its job, keep it. If you'd rather run your own search work on whatever your site is built on, that's what I teach in SEO Without an Agency.
The signs are workarounds, not age. You're paying for add-ons to patch missing features, your team retypes enquiries into other systems, the design can't carry your brand, or you can't change something search engines need. One sign is a nuisance. Three or more around the same problem usually mean the platform has become the limit.
| Sign | What it usually means |
|---|---|
| Add-ons stacked on add-ons to get one feature working | The platform wasn't built for what you're asking of it |
| Staff retype form enquiries into your CRM or booking system | The site needs to connect to your systems, not sit beside them |
| The site looks like everyone else's in your industry | The layouts can't carry the standard your brand holds in person |
| You can't control a URL, a redirect, structured data or how a page loads | You've lost control of the parts search engines read |
| Pages get slower every time a feature is added | Platform code and add-ons are loading on every page |
| Clients, members or staff need logins, portals or bookings | The site is turning into an application |
| Nobody can say what you'd keep if you left the platform | You're renting something the business now depends on |
When the site is turning into an application, the question shifts from websites to software. Here's when a custom app beats off-the-shelf software.
Yes. Between a drag-and-drop builder and a site built from scratch sits a purchased theme on a content management system, the software many sites use to manage their pages. It's more flexible than a builder, through themes and plugins, but it still starts from someone else's structure, and every plugin is one more thing to keep updated.
| Option | What it is | Fits | Where it stops |
|---|---|---|---|
| Website builder | A hosted platform with layouts and a drag-and-drop editor | Brochure sites and businesses still finding their shape | The platform's features, layouts and settings |
| Theme on a content management system | A purchased layout on a self-managed platform, extended with plugins | Content-heavy sites with standard needs | Plugin conflicts, constant updates and the theme's structure |
| Custom build | Structure, code and integrations built for one business | Sites that carry a premium brand, connect to systems or need full search control | Needs scoping, a build and someone responsible for it after launch |
We build custom, on Replit, so every route, redirect and piece of markup is part of the build itself rather than a setting someone hopes an add-on respected.
Not by themselves. Search engines rank pages, not platforms, and a well-run builder site can rank. The cost is control: on a builder you get the URL, redirect, markup, speed and rendering settings the platform exposes, and nothing more. When a fix you need sits outside those settings, you can't make it.
AI assistants raise the stakes. Many AI crawlers don't run JavaScript, so content that only appears after scripts load may be invisible to them, and on a builder the platform decides how your pages render.
A custom build puts every one of those settings in your hands. Whether that's worth paying for depends on how much search drives your business. If it drives a lot, that's where SEO and AEO work earns its place.
Treat it as a migration, not a redesign. Moving off a builder almost always changes your URLs, so list every old address, map each one to its closest new page, and set a permanent 301 redirect for every one. Export what the platform allows before you cancel, and keep the old account until the move is confirmed.
Google says most pages on a small or medium-sized site can take a few weeks to move to new URLs, and recommends keeping redirects in place for at least a year. Its guidance on site moves covers each step.
Check what you can take with you before you commit. Depending on the platform, page text, images and blog posts may export, while the design and add-on features often stay behind. If your domain was registered through the builder, move it to a registrar account in the business's name before launch day.
Expect a dip while search engines re-crawl, and judge it by how quickly it levels out. Here's how to protect rankings during a rebuild, step by step.
A builder costs a subscription plus whatever add-ons you need, paid for as long as the site exists. A custom website costs a build up front, then hosting and ongoing maintenance. The fair comparison runs over the years you'll actually use the site, and it includes the staff time the builder's workarounds are already costing you.
| Cost | Website builder | Custom website |
|---|---|---|
| Upfront | Setup time and a layout | Scoping, design and the build |
| Running | The subscription, which usually rises with your plan | Hosting and maintenance |
| Features | Paid add-ons, often billed separately | Built into the site |
| Changes | Within the platform's limits, or not at all | Scoped and built when you need them |
| Hidden cost | Staff time on workarounds and retyped enquiries | An unclear owner for updates after launch |
| Leaving | Rebuilding whatever doesn't export | Moving hosting, if the code and accounts are yours |
SyncDS doesn't publish prices. Every build is custom-quoted, with no packages or tiers.
Ask about life after launch as much as the design. Who owns the code, the domain and the accounts? How will your team edit pages? Who maintains the site, and on what terms? How are redirects from the old site handled? A builder answers some of these for you. A custom build needs every answer in writing.
Accessibility deserves its own line in the contract, especially for public-sector work. WCAG 2.2, published by the W3C, is the international standard that accessibility laws and policies commonly reference.
The ownership question matters more than it looks. It's the line between what you keep when a contract ends and what you've only been renting.
Stay on a builder while the site is a brochure that does its job. Go custom when the site has to connect to your systems, carry a premium brand or give you full control of search, and the workarounds are already costing more than they save. Whichever you choose, keep the domain and accounts in the business's name.
| If… | Then |
|---|---|
| The site is a brochure and enquiries arrive as they should | Stay on the builder |
| You're still proving what the business sells | Stay on the builder and revisit once it settles |
| You're paying for add-ons to patch missing features | Weigh the cost of the workarounds against a build |
| The site needs logins, bookings or a connection to your systems | Scope a custom build |
| Your brand operates at a level the layouts can't show | Scope a custom build |
| Search drives the business and you can't control what search engines read | Scope a custom build, with a migration plan |
A site designed and built for one business, rather than assembled from a layout made for many. Its structure, design, features and integrations are scoped to how the business works. Custom should also mean you can see and keep the code, not just that someone changed the colours on a theme.
It depends on the number of pages, the features, what the site connects to, how much content moves over and what happens after launch. Anyone quoting a firm number before scoping is guessing. Every SyncDS build is custom-quoted, with no packages or tiers.
For a brochure site you'll update yourself, a builder is the faster route than hand-coding one, and it handles hosting for you. If the site needs to connect to your systems, carry a premium brand or give you full control of search, neither fits, and a custom build is the better route.
It is when the site has to do work a builder can't: connect to your systems, carry a premium brand or compete hard in search. It isn't when a brochure site already brings in the enquiries you need. Weigh the cost of a build against what the builder's limits are costing you now.
No. Search engines rank pages, not platforms. The limit is control: you can only change the URLs, redirects, markup and speed settings the platform exposes. For a small site that's usually enough. For a business that competes hard in search, the settings you can't reach start to matter.
You can keep most of them with a full URL map, a permanent redirect for every old address and the new sitemap submitted on launch day. Expect a dip while search engines re-crawl. Check what the platform lets you export, and move the domain into your own registrar account first.
They should be able to. A custom build should include a way to edit the pages and content your team changes often, without calling a developer. Ask to see the editing setup before the build is signed off, and agree which changes will still need a developer.
You should, but the contract decides it. Get written terms on who owns the code, the domain, the hosting account and the analytics. If the site runs on the developer's accounts and stops when you stop paying, you've rented it, not bought it.
When it stops doing its job, not on a calendar. A brand that has moved upmarket, a site that can't support a new service, slipping speed or search performance, or a platform you've outgrown are better triggers than a date. Improving what works often beats rebuilding it.