Custom website or website builder?
Use a website builder when its content model, templates and supported integrations meet the requirements. Consider a custom build when an important workflow or constraint does not fit. The decision should include maintenance and exit costs, not just the first invoice.
Compare the constraint, then the tool.
Use the actual platform plan and the actual custom proposal for this comparison. Neither approach automatically delivers a fast, accessible or search-friendly site. Ask to test the requirement that matters to your project.
| Requirement | Check in the builder | Check in a custom proposal |
|---|---|---|
| Routine publishing | Can your editor create every required content type without developer help? | Who builds and maintains the editor and its preview workflow? |
| Private client records | Does the real plan enforce access to each record, beyond hiding a page? | Are permissions defined and tested where the data is served? |
| Business integration | Does the supported connector cover your fields, failures and account plan? | Are retries, failure reporting and provider changes included? |
| Search and performance | Can you control URLs, redirects and indexing on the pages you need? | Who verifies those controls and the deployed page experience? |
| Leaving the setup | Export a sample of content and assets. Check what remains runnable. | Build the source from the handover notes and identify hosted dependencies. |
A builder can be the right tool.
A small company site with standard pages, a simple publishing workflow and a supported form may not need a custom application. A builder can let the team work inside an existing editor and reuse established components.
Check the actual product and plan you would buy. Content limits, export options, integrations, accessibility controls and account permissions vary. Do not compare a concrete custom proposal with an imaginary platform that has every feature.
Custom work is justified by a specific constraint.
A complex content model, unusual interaction, private customer workflow or integration with an internal system can make a template a poor fit. Write down the requirement that is blocked and test whether the platform can support it before rejecting the platform.
Custom does not mean building every layer yourself. A custom interface can use an established CMS, commerce system or hosting platform. The useful question is which part needs control, and which existing parts can do their job unchanged.
Compare what you can change and take with you.
Ask what can be exported: content, media, customer data, templates and source code are separate things. Also ask what remains usable after a subscription ends. An export button may provide the data without providing a runnable website.
A custom build also has dependencies. Libraries have licences, infrastructure has costs and an unfamiliar codebase needs documentation. Owning a repository is useful only if someone can build, deploy and maintain what it contains.
Price the work after the launch too.
Compare the same period of operation. Include subscriptions, hosting, paid integrations, support, content changes and the effort to leave the platform. Avoid pretending that either option is free to maintain.
For example, a standard company site might favour a builder even if a custom design is possible. A portal where customers review private documents may need application-level permissions and workflow rules. The visual complexity alone does not tell you which option fits.
Test the difficult requirement first.
Choose the one requirement most likely to break the decision: a data relationship, a permission boundary or an external integration. Confirm it in the real platform before building the rest of the plan around it.
BRÈCHE builds custom websites when that approach fits the requirements. A brief that names the constraint lets us explain the tradeoff instead of prescribing custom code for every project.
The checklist.
- The most difficult requirement is written down and tested.
- Editing roles and content types fit the proposed tool.
- Exports and account ownership are understood.
- Initial and recurring costs cover the same scope.
- Someone is responsible for maintenance.
- There is a practical path to leave or extend the system.