On this page7 sections
I build both. Some of my clients run on WordPress with a design I made for them. Others run on a custom site I wrote from scratch. Neither one is the "better" answer on its own. The right one depends on your team and your customers, not on the platform's reputation.
When proposals disagree about the platform, this guide is how I make the call. It comes down to three things: who edits the site, what customers have to do on it, and who looks after it once it's live.
The question is three questions
"WordPress or custom?" bundles three decisions into one word, so I pull them apart.
Design is what the site looks like and how it behaves: layout, type, navigation, motion, and whether the page helps someone decide. Using WordPress does not mean using a generic theme. WordPress publishes a full handbook for developers building their own themes, and that's what I do. WordPress: Theme Handbook
Publishing is how your team adds and changes content: draft, preview, approve, publish, fix a mistake. This is the part most proposals skip and the part that decides whether the site is still current in a year.
Business logic is what happens to records, payments, permissions and connected tools. A site that explains your services has almost none. A customer workspace with invoices and project files has a lot.
When a proposal says "custom," I want to know which of these it means. Original design on WordPress? A custom theme with a few plugins? A separately built frontend pulling content from a CMS? An application with its own database? Those are four different scopes, not four grades of quality.
How I decide
I start with the next person who has to edit the site. I ask what they change in an ordinary month: a project, a service detail, a team member, an image. Then I ask them to picture doing it at four o'clock on a Thursday.
If your team publishes regularly and wants to do it themselves, I lean WordPress with a custom theme. I curate the editor so the team can change words and images without breaking the layout. WordPress documents block locking and editor curation for this, and I design the account permissions alongside it. WordPress: curating the editor
If the site is a focused set of pages that changes a few times a year and needs to be very fast and very specific, I lean custom. There's less to maintain, and I control every byte the browser downloads.
If customers need to log in, approve things, pay in installments or see their own records, the platform question is secondary. That's an application. It can sit beside a WordPress marketing site or replace it, and I scope it as a system either way.
If the current site has one serious problem, I don't recommend a platform change until I've found the cause. A content problem, a broken connection or a slow template deserves a diagnosis. Rebuilding on a new platform can carry the same problem into a more expensive project.
The five approaches, and what I check on each
| Approach | Where I'd use it | What I check before recommending it |
|---|---|---|
| Hosted website builder | Content and tasks fit the product's editor and connections | Product limits, subscription terms, what you can export, who owns the account |
| WordPress with an existing theme | A site that fits a good theme with few extensions | How much customization it really needs, and the ongoing theme and plugin upkeep |
| Custom WordPress theme | Distinctive design plus a team that publishes | Editorial controls, dependencies, and how the site is handed over |
| Custom frontend with a CMS | A public experience that benefits from separate presentation and publishing | Preview, publishing, deployment, and who owns two systems instead of one |
| Custom application | Records, permissions and behavior that need their own implementation | Whether existing software already does it, and how it will be tested and maintained |
These combine. WordPress has a REST API, so a separately built frontend with WordPress publishing behind it is a real option when there's a reason for the extra part. A custom application can sit beside the marketing site your team already knows. WordPress: REST API Handbook
Turn your situation into a comparison brief
I built this planner so you can run the same customer task and the same editing task against each option. It gives you a shortlist and a set of demonstrations to ask for. It won't pick a platform for you, and it won't score vendors.
Compare the work your website needs to do
Hosted builder
- Editing
- Included editor, within the product’s limits
- Ongoing ownership
- Provider operates the platform; someone still owns your content and connected tools
- Ask to see
- Try the exact integration and content export before committing
Custom WordPress
- Editing
- A familiar CMS with a deliberately designed editing experience
- Ongoing ownership
- Name owners for core, themes, plugins, hosting, and recovery
- Ask to see
- Publish your real content in the proposed editor
Custom frontend + CMS
- Editing
- A chosen CMS connected to a separately built public site
- Ongoing ownership
- Name owners for the CMS, frontend, deployment, and integrations
- Ask to see
- Prove preview, publication, export, and ongoing handoff
Put the editing experience at the center
Compare a curated WordPress editor with a suitable builder and another CMS approach. The best fit is the one your team can actually publish with. Name the maintainer and agree the ongoing work before approving a custom implementation.
- Add a project with real text and images
- Preview phone layout and revise a draft
- Export content and show who can publish
These are approaches to discuss, not vendor scores or a platform recommendation generated from three answers. A custom application may be a separate system. Selections remain local to this page until reload.
Keep the brief with the proposals. A good proposal shows why the chosen approach fits your work, what you're trading away, and how your team owns it after launch.
What each one costs to run
The platform doesn't set the price. For my own work, websites sit in a $4,000–$10,000 planning range whether they're WordPress or custom. Focused improvements are $1,000–$3,000, and a site that's really a business system is $8,000–$20,000+. The website cost guide explains what moves a quote inside those ranges.
WordPress being free to download does not make a designed, built and maintained business website free. A hosted builder includes a lot of platform operation but still needs design, content and connected services. Custom work needs someone who can maintain it.
I compare every option on the same lines: initial design and build, content and migration work, hosting and subscriptions, connected services like booking or mail, ongoing upkeep and content changes, and the handoff: accounts, documentation and a practical exit. A low build price tied to a subscription you can't leave is a different deal from a separately priced build and a monthly plan you can cancel.
Speed and search are results, not platform features
WordPress is not a promise of a slow site, and custom code is not a promise of a fast one. Images, fonts, scripts, third-party tools and hosting decide the speed you actually get. I measure representative pages before and after, and I keep lab scores separate from real-visitor data. PageSpeed Insights reports both. Google: PageSpeed Insights
Good code and good hosting work together. When a project is hosted with DreamHost, DreamHost provides the hosting and I handle the code and asset work. I'm DreamHost's CMO; the hosting is DreamHost's product and billed separately, and the work described here is my own.
Search works the same way. Google's SEO Starter Guide is about clear content, useful titles, linked pages and stable addresses. No CMS purchase buys a ranking. An SEO plugin gives you controls; someone still has to decide what goes in them. A custom site generates the same underlying elements, and I show you the output on a real page either way. Google: SEO Starter Guide
Who looks after it
WordPress upkeep means core, theme, plugins, access, backups and hosting. A custom site means a framework, libraries, deployment and any connected services. A hosted builder takes on some of that and leaves content, accounts and workflows with you. WordPress's own security guidance treats hosting and application responsibilities as related but separate, and frames security as reducing risk rather than removing it. I think that's the honest framing for any platform. WordPress: hardening guidance
Whatever I build, you get the domain, the content, the service accounts and the source or configuration for the agreed work, plus documentation another developer could pick up. If you want me to keep looking after it, that's a scoped monthly management plan. If you'd rather your team owns it, the handoff is designed for that.
WordPress and custom are both good answers. The right one depends on who edits the site, what customers have to do on it, and who maintains it after launch. A team that publishes often usually points to a custom WordPress theme with a curated editor; a small, fast, specific site usually points to custom. The platform name doesn't set the price.