WordPress is the right choice when a team will edit content often, the site is corporate or editorial, and you need to publish soon on a tight budget. A custom website is the right choice when performance and security come first, there is business logic of your own or complex integrations, and the site will evolve like a product. The decision depends on who edits, what the business demands and who maintains the site, not on whichever technology is fashionable.
It is one of the first decisions in any web project and it is usually framed as a war between camps. In practice it is a question of fit: what you need today, what you will need in two years and who is going to maintain the site. I have built and maintained both, and both can turn out well or badly. What makes the difference is answering these five questions honestly before choosing.
The five questions that matter
1. Who will edit the content, and how often?
If your marketing or admin team wants to publish articles, change copy, upload photos or add pages without asking for help, a content management system like WordPress is a clear advantage: the editor, media library, drafts and per-user permissions already exist. On a custom website that editing has to be built or wired to an external CMS, and that costs time and money.
But be honest about frequency. If the site will change twice a year and the same supplier will always make the changes, a comfortable editor adds little. A useful question: who touched the website in the last six months, and how many times?
2. What performance and security do you need?
A well-built WordPress site can be fast and pass the Core Web Vitals, but that depends on the quality of the theme, the hosting and keeping plugins to a minimum. Every plugin adds code to the server and, often, CSS and JavaScript to every page. A static or custom website loads only what the design needs and, by design, has a smaller attack surface: no public admin panel, no exposed database, no third-party dependencies to update every week.
If performance or security is critical (e-commerce with traffic spikes, a regulated sector, sensitive data), that difference carries weight. If it is a corporate website with moderate traffic, a well-kept WordPress site is more than enough.
3. Are there integrations or logic of your own?
Contact forms, simple bookings, catalogues without pricing logic and blogs are handled well by plugins. Processes with their own logic (product configurators, calculated quotes, client portals with documents, two-way connections to an ERP or CRM) are usually cleaner and easier to maintain as a custom build. It can be done in WordPress, but you end up fighting the platform and depending on the plugins you chained together staying compatible with each other.
Example: a machinery rental company that wants customers to see real availability, book and download their contract. That is an application with a website in front of it, not a website with a booking plugin.
4. What is the budget, including maintenance?
The initial cost of WordPress is usually lower. But it pays to add up what comes afterwards:
| Maintenance task | WordPress | Custom or static website |
|---|---|---|
| Update core, theme and plugins | Monthly or more often; check compatibility | Development dependencies; no panel to patch |
| Backups | Files and database, with a restore test | Code in a repository; data only if there is an application |
| Security monitoring | Malware scanning, login attempts on the panel | Uptime and header monitoring |
| Performance review | After every update that adds code | After every design change |
| Content changes | Done by the team | Done by the team if there is an editor; otherwise by the supplier |
A custom website costs more up front and usually has lighter maintenance. WordPress costs less up front and demands a monthly routine that someone has to carry out. Neither is "free" after launch. Always ask for the three-year cost, not only the project cost.
5. How soon do you need it?
With existing themes and components, WordPress shortens timelines: a ten-page corporate website can be live in a few weeks. A custom website requires design, development and testing before the first release. If there is a fixed date (a trade fair, a launch), that alone can decide it.
Side-by-side summary
| Criterion | WordPress | Custom |
|---|---|---|
| Content editing | Very comfortable, built in | Has to be built or connected |
| Performance | Good if code and plugins are kept in check | Excellent by design |
| Security | Requires updating and monitoring | Smaller attack surface |
| Complex integrations | Possible, with plugins and custom code | Cleaner and more controllable |
| Initial cost | Lower | Higher |
| Maintenance cost | Mandatory monthly routine | Lighter |
| Timeline | Shorter | Longer |
| Supplier lock-in | Low: any agency knows it | Medium: requires documentation and delivered code |
Common mistakes with WordPress
- Piling up plugins. Each one adds code, risk and maintenance. Running three form systems at once, or two caching plugins, is a typical example of excess. My rule: if you do not know what a plugin is for, deactivate it and see what breaks.
- Heavy multipurpose themes. Visual builders with hundreds of options load CSS and JavaScript the site never uses and hurt LCP and INP.
- Unoptimised images. Photos of several megabytes are uploaded straight from the camera and the site becomes slow on mobile.
- Not updating. An unpatched site is the most common entry point for attacks. Most known WordPress vulnerabilities are in plugins and themes, not in core.
- Default SEO settings. A badly configured plugin can leave key pages in
noindexor block resources. I explain this in why your website does not show up on Google. - The "admin" user and weak passwords. The panel sits at a well-known URL and receives automated login attempts from day one.
Common mistakes with a custom website
- Not handing over the code or the documentation. If you change supplier and nobody knows how the site is deployed, you have a problem. Require a repository, deployment instructions and ownership of the code by contract.
- Building an editor nobody uses. If the team will not touch the content, a custom editor is money thrown away. And if they will touch it a lot, an existing CMS usually works out better than a bespoke one.
- Reinventing what is already solved. Authentication, email delivery, media management: mature services and libraries exist. Doing it from scratch multiplies cost and failures.
- Forgetting maintenance. "Custom" does not mean "no dependencies". Libraries get updated too, and they have security advisories too.
When to choose each option
There is also a middle ground I use often: a static site for the public pages (fast, secure, cheap to host) with a separate CMS for the blog or the listings that change. WordPress can be that CMS without serving pages to the public. The team edits in a familiar environment and the visitor receives plain HTML. The cost is a bit more architecture at the start.
Questions to ask your supplier
- What happens if I want to change agency in two years? What do I take with me?
- How many plugins or external dependencies will it have, and which are essential?
- What does the monthly maintenance include, and what does it not?
- How are performance and security measured before delivery?
- Who is responsible for backups, and how often is a restore tested?
If in doubt, the discovery phase of a web project exists precisely to decide this with data from your case rather than generalities. And whichever option you choose, the security checklist applies just the same.