Answer in brief
A dated template is no reason to move. The reason arrives when the platform stops letting you do the work: page speed, data export, an integration that needs a server, a bill tied to traffic. Four ceilings, and what each answer costs.
The short answer: a limit counts when it starts blocking work: A builder stops being enough when a named platform limit…
A website builder stops being enough not when the template feels dated, but when a specific platform limit blocks work you need done: the page will not get faster, the data will not come out, the integration will not stand up, the invoice climbs with traffic.
Those are four separate ceilings and they arrive at different moments. Plenty of businesses never meet any of them, and a brochure site on a builder can run for years with no reason to move. Other companies hit the first one in month two.
The test is plain. Name the job you cannot do, then explain what is actually blocking it. If the blocker is your own build — heavy photographs, stacked widgets, scripts nobody ever removed — it can be fixed inside the builder you already pay for.
If the blocker is how the platform is made — someone else's runtime, a closed server side, a plan priced by traffic — then the tool itself has to change. The rest of this piece takes the ceilings one at a time and ends with what each answer costs.
What builders genuinely do well, and why leaving early is expensive
A builder takes hosting, certificates, engine updates and most of the markup off your desk. For a five to seven page site with a contact form that is a fair trade: you pay a subscription instead of paying for the same work in developer hours.
It also lets you edit without a developer. The owner changes a price, a paragraph or a photograph the same afternoon, with no ticket and no release to wait for. On a small team that removes days of waiting from every minor correction.
Moving costs money and attention: transferring content, keeping page addresses alive, rebuilding forms and analytics, retesting everything on phones. While no ceiling is costing you revenue, that budget does more good somewhere it can earn instead.
So the question is not whether custom development wins in the abstract. It is whether you have run into something specific and nameable. Below are the four ceilings, each with symptoms you can recognise without a developer in the room.
Ceiling one: page speed you cannot move from the inside
On a builder you control what sits on the page, but not the delivery layer underneath it. The platform decides which scripts run on every page, how the stylesheet is bundled, which image sizes and formats are served, and when the fonts load.
Some of it is still yours. Heavy photographs, embedded video, chat widgets and tracking pixels were added by someone on your side, and someone on your side can remove them. Start there, because that layer usually moves without changing platform at all.
Past it sits the part you do not own: the editor runtime, the template markup, the order in which styles arrive. That ceiling is firm. It moves when the platform ships an update, not when you change a setting in your own panel.
Separating the two layers is a measurement job: how many bytes arrive, what blocks the first render, how much work lands on the main thread. The MDN Web Docs performance material defines those measures without tying them to any one vendor.
Ceiling two: owning the data, the export and the addresses
An export from a builder generally hands back content: text, image files, sometimes a table of orders or enquiries. It does not hand back the built site. Templates, blocks and editor components stay with the platform that made them.
The practical consequence is that a move is not an unzip. It is a rebuild in which your own content is the input material, and pricing it as free is the quick route to a surprise. That is one more argument against moving without a reason.
Three things belong in your hands from day one, whatever platform you use: the domain registered in your own registrar account, the analytics property in your own account, and a copy of every enquiry held outside the builder by email or scheduled export.
Page addresses deserve their own line. They accumulate links and search history, and a move either preserves them or redirects them. Export the address list early, while the subscription is live and the admin panel still opens for you.
Ceiling three: integrations that need a server of your own
Builders cover the ordinary cases well: an app directory, embeddable code, an event pushed to an outside service. While the integration means form submitted, external system notified, platforms generally handle it without complaint.
The ceiling appears where your own server-side logic is required: receiving a webhook and verifying its signature, running a scheduled background job, writing into a database you own, or a customer area with roles and access rules of your own.
There is also a security constraint that embedded code cannot get around. A key placed in a script on the page is readable by every visitor. Keys that must stay private have to live on a server, and a builder rarely hands you one.
The check before deciding: list every system the site must talk to, and against each one write who starts the exchange, where the secret is stored, and what should happen when the call fails. An app will close some of those rows and not others.
Ceiling four: a bill that grows with traffic and catalogue
A subscription looks fixed, but the total is assembled from several lines: a plan tier tied to traffic, storage or product count; monthly fees for installed apps; paid seats for staff; and a percentage taken on certain commerce plans.
While the site is small those lines stay invisible. They become visible exactly when the business grows, which is the moment a migration is least convenient to start. That calendar is better planned for in advance than discovered mid-year.
Do the sum over a horizon rather than a month. Take your last twelve invoices, add every app on top, and multiply by two years. Put a second column beside it: one build, plus monthly support at a stated rate.
At VITON13 that second column reads: Launch Site at $380, Product Build at $880, Ongoing Dev Support at $290/mo. The two columns are only comparable together with what each side stops doing for you in exchange.
Accessibility and semantics: where a template helps and where it fights you
A template usually arrives with sensible defaults: a heading structure, a field for alternative text, a visible focus state on controls. That is a starting position rather than a finished result, and editing drifts away from it quickly.
It breaks inside the visual editor. Heading levels get chosen by font size, links get dressed up as buttons, text colour gets picked by eye, and a control that is comfortable with a mouse ends up smaller than a thumb on a phone.
The W3C quick reference for WCAG 2.2 sets checkable targets: contrast from 4.5:1 for ordinary text, a minimum pointer target size of 24 by 24 CSS pixels with the stated exceptions, a visible focus indicator, and operation from the keyboard.
Part of that is fixable inside the builder in an evening: alternative text, heading order, control sizes. Part depends on the template itself, such as element order in the markup and focus styling. That line is the border between a fix and a move.
Telling a platform ceiling apart from your own build
The procedure is the same whether the complaint is speed, a form or layout. Create an empty page on the same template, with no embedded widgets and no third-party scripts, and run exactly the same test on that page.
If the problem disappears on the clean page, the ceiling is not the platform. It is what has accumulated on your working page, and it is fixable with settings and deletions, without leaving the subscription you are already paying for.
If the problem survives, get the next distinction straight: is this a plan limit, a template limit, or a platform limit. The first is solved with money, the second by changing template, and the third is not solved at all.
Ask the platform's support team for that answer in writing before you commission a migration. A move started on a hunch sometimes ends with the discovery that one widget in the footer was doing all of the damage.
When the answer is not a rebuild: the $70 fix pack: A share of speed and accessibility complaints comes from…
Site Fix Pack costs $70. It covers up to five agreed fixes, a check on mobile and desktop, and a before and after list at handover. The timeline is 1-2 working days, with one round of revisions.
The format matches that first layer precisely: heavy images, scripts nobody removed, a form that stopped delivering mail, a block that collapses on a phone, missing alternative text, a control that is hard to hit with a thumb.
The exclusions matter as much. New pages, redesign and migrations are not part of the pack. If your list opens with the word migrate, that is different work under a different package, and naming it at the start avoids an argument halfway through.
The point of the step is that it buys an answer for very little. Five fixes either settle the complaint or they do not, and in the second case you commission the move already knowing the cause instead of guessing at it.
When the answer is a move: Launch Site and the express route: The domain, the analytics property, a copy of every…
Launch Site costs $380: a responsive build, core CMS or data wiring, and deployment setup. The timeline is 3-5 working days, with two rounds of revisions before launch, which suits a small site with a settled structure.
One condition belongs in the conversation before the start: content and translations are supplied by the client. Text, photography and language versions are not inside the package, and without them a build stalls on empty blocks.
Launch Site Express costs $520: the same scope in a priority queue, with daily builds, a launch checklist and a handover call. The timeline is 2 working days, with one round of revisions after the first full build.
Content, photography and ongoing support sit outside the express package. The difference between the two is not the size of the site but the queue and the rhythm, and the price of that rhythm is being available to answer the same day.
When what moves is a product, not a site
If your list of limits has grown into accounts, roles, calculations or request logic of your own, the thing you are building is no longer a site. Product Build costs $880: feature delivery, state and route logic, testing and hardening.
The timeline there is 2-3 weeks, not working days, with two rounds of revisions per delivered feature. The boundaries are stated plainly: native mobile apps and payment licensing sit outside the package, and that is said at the start.
After launch there is work that does not end: dependency updates, small corrections, watching what the system actually does in production. Ongoing Dev Support costs $290/mo and covers priority updates, a weekly release rhythm and technical maintenance.
Remember its terms exactly. The cycle is monthly, stopping it takes 30 days notice, and the volume of work is agreed at the start of each cycle. A new build or a redesign is not inside support and is scoped separately.
How to decide within a week without breaking anything
Day one: write one line describing what you cannot do. Not the site is slow, but the catalogue page takes longer to open than we accept, and the platform gives us no way to remove the scripts it puts there itself.
Days two and three: run the clean-page test and get the platform's answer in writing. By the end of those two days you know whether you are looking at a plan tier, a template decision, or the way the service itself is built.
Day four: export the page address list and a copy of your enquiries, and confirm that the domain and the analytics property sit in accounts you control. That work pays off in both outcomes and loses its value once the subscription lapses.
Day five: choose the step. Five fixes at $70 if the ceiling turned out to be yours; a build at $380 or $520 if it belongs to the platform; $880 if a product has grown out of the site. A decision made that way rests on a test rather than on fatigue with a template.
Practical checklist
- Write in one line the job the current site will not let you do.
- Repeat the test on an empty page of the same template with no widgets or third-party scripts.
- Ask the platform's support team in writing whether the limit belongs to the plan, the template or the service.
- Export the page address list and a copy of your enquiries while the subscription is still live.
- Confirm that the domain and the analytics property are registered in accounts you control.
- Add up your last twelve invoices with every app included and set them beside one build plus monthly support.
Questions and answers
How do we tell whether the problem is the builder or our own site?
Build an empty page on the same template, with no embedded widgets and no third-party scripts, and run the same test on it. If the problem disappears, the ceiling is yours and settings will fix it. If it survives, ask the platform's support team in writing whether the limit belongs to the plan, the template or the platform.
What does it cost to test the theory before committing to a move?
$70. Site Fix Pack covers up to five agreed fixes, a check on mobile and desktop and a before and after list at handover, in 1-2 working days with one round of revisions. New pages, redesign and migrations are not included, so a move is quoted separately.
How long does moving to a custom build take?
Launch Site costs $380 and takes 3-5 working days, with two rounds of revisions before launch. Launch Site Express costs $520 and takes 2 working days, with one round of revisions after the first full build. Content and translations are supplied by the client in both cases.
Will we lose search traffic when we move?
No one can guarantee a position, and there will be no promises here. The controllable part is the addresses: export the list before the move, keep the addresses that have already collected links, and set redirects for the ones that have to change. Test those redirects before the switch, not after.
When is this a product rather than a site?
When accounts, roles, calculations or request logic of your own appear. Product Build costs $880: feature delivery, state and route logic, testing and hardening, over 2-3 weeks, with two rounds of revisions per delivered feature. Native mobile apps and payment licensing are outside the package.