WordPress vs custom website: eight questions to settle first

WordPress vs custom website sounds like a question settled by company size or by budget, and it is settled by two entirely different things: who actually maintains the site and how often its content changes. Every supplier answers it their own way, because everyone recommends what they build most often. Below are eight deciding questions you answer yourself, before the conversation starts — each one says plainly what the answer implies for the platform.

What actually settles WordPress vs a custom website

The platform follows from the maintenance model, not from the scale of the business. The three options compared here are: a ready-made CMS installed on your own hosting (WordPress and its relatives), a site coded for one specific project, and a subscription platform where the software and the server belong to the vendor.

They differ not in “quality” but in where responsibility sits. On a ready-made CMS you have full control over the code and full responsibility for updates. On a custom-coded site you control what reaches the browser, but every change in functionality goes through the supplier. On a subscription platform the vendor takes maintenance off your hands and, in return, limits what you are allowed to change.

If budget is the sharpest constraint today — the company is only starting out and the site is a brochure with a contact form — begin small and come back to this choice when the requirements are real rather than imagined. Describe what the site has to do and the shortlist usually narrows on its own.

Questions 1-4: who works on this site every day

1. Who will edit the content, and how often

If the answer is “a non-technical person, a few times a month”, an editing panel is value rather than decoration — you are heading towards a ready-made CMS, or a coded site with a headless CMS attached. If it is “once a quarter, and through the supplier anyway”, the panel is a maintenance cost, an update cost and one more attack surface you pay for without a return.

2. How many integrations with external systems are in play

Zero or one standard integration (a form to a mailbox, a newsletter, payments) fits inside the plugins of a ready-made CMS and argues for nothing. Three or more — especially with your own ERP, warehouse, booking system or CRM — means the heart of the project is system integration, not the visual layer. The platform is then decided by how comfortably you can write your own integration code in it and keep that code working through updates.

3. Who is responsible for security updates, and on what schedule

If you cannot name a person and a time window (“within 48 hours of a patch being released”), choose a setup where somebody else installs updates: a subscription platform, or a maintenance agreement with the supplier. “We will install them and it will be fine” is in practice a decision that within a year the site will be running on out-of-date components — whichever platform it sits on.

4. How many pages will actually exist, and will they grow

A dozen or so fixed pages with settled content is the case where a database and an editing panel do not earn their keep. Hundreds of entries, categories, filtering, several authors and content added every week is the opposite case — you need a content model and a panel, and the question narrows to whether that panel sits inside the presentation layer or separate from it.

Questions 5-8: what happens to this site in two years

5. Does the platform produce accessible code by default

The answer is always “partly” — no platform is WCAG-conformant on its own, because conformance depends on the implementation and on the content you type in. The practical question is about control: can you change the heading structure, the field labels and the focus order without fighting the theme. The requirements and the reference level are covered separately in the piece on website accessibility under the European Accessibility Act; the technical standard cited for EU conformance is EN 301 549, which points to WCAG at level AA for web content.

6. How much control do you have over URL structure and structured data

If you cannot change the URL pattern without a plugin or without raising a ticket with the vendor, every future change to the information architecture becomes a migration project with redirects — a separate operation described in the guide to website migration without losing rankings. Check as well whether structured data (product, article, local business) can be edited at template level, or only through fields added by a plugin.

7. What is the cost of leaving, and can you export the data

This question is asked least often and its consequences are the most expensive, so it has its own section below. At this stage one determination is enough: can you name today the format in which you would get back content, media and customer data.

8. Who will be maintaining this site in two years

“The same agency, we have a contract” opens the door to less common solutions, because the risk of somebody else having to take the code over is low. “I do not know” or “an in-house team that does not exist yet” narrows the choice to technologies with a wide supplier market and public documentation. If you want suppliers to answer these eight questions comparably, write them into a document — how to build one is covered in the piece on the software project brief.

Three options side by side: what really separates the platforms

A slow site: what happens on the server and what happens in the browser

Separating those two layers changes both the diagnosis and the cost of the fix, so do it before the platform decision. On the server side sit time to first byte, HTML generation, database queries and caching. On the browser side sit downloading and executing JavaScript, image weight, fonts, third-party scripts (chat widgets, analytics pixels, consent banners) and layout shifting during load.

The consequence is straightforward: stronger hosting improves only the first group. If external scripts and images slow the site down, moving to a faster server — or to a different platform — changes nothing, because the problem travels with the content. Measure both layers with tools you already have: PageSpeed Insights, Lighthouse, Chrome DevTools, Google Search Console, the web-vitals library and WebPageTest.

The thresholds themselves, and the fact that the assessment is built from CrUX field data over a rolling 28-day window, at the 75th percentile and separately for mobile and desktop, are covered in the article on Core Web Vitals.

The cost of leaving and data export: the question asked least often

The cost of leaving is the work needed to move a site to another platform without losing content, customer data and URLs. What counts is not “is there an export” but what it covers. Page content, images at original resolution, products with variants, orders, customer accounts, reviews, the mapping of old URLs onto new ones — each set can be a separate case.

In Polish e-commerce the difference is visible with the naked eye, and a company operating in Poland is likely to be running one of these already. In self-hosted solutions such as WooCommerce, PrestaShop or Magento (Adobe Commerce) you have access to the database and the files. In the subscription model — Shoper, IdoSell, Shopify, Sky-Shop, Selly, AtomStore — you get what the vendor exposes in the panel and through the API. Both models are used by large shops; they differ in what it costs to leave. When the project is a shop rather than a website, that trade-off gets its own six criteria in the guide on picking a hosted or a custom online store.

An answer of “we will write a script when the time comes” is a negative answer. A concrete answer names the formats and the scope, and it can be written into the contract.

When optimising an existing WordPress still pays off

It pays off as long as the fixes hold — as long as a theme or plugin update does not undo them. Typical situations on this side of the line: a classic or lightweight theme, a dozen or so plugins each of which you can justify, hosting you can upgrade within the same contract, and a problem list that reads uncompressed images, no caching, and four marketing scripts of which two are dead.

Architecture is the problem when the layout comes from a page builder generating nested containers that cannot be simplified without rebuilding the template; when dozens of plugins have overlapping scopes; when some have had no update in a long time; when every performance fix needs a workaround and the result disappears at the next update. In that setup maintenance costs grow unpredictably, while a rebuild gives a scope of work you can count.

WordPress itself is not the culprit here — the same diagnosis fits a custom-coded site that had scripts piled onto it for three years without review. The line is drawn by whether changes are reversible, not by the name of the platform.