WordPress or custom development.
WordPress is a ready-made content management system that gains most of its functions through themes and plugins; in custom development, the site is built with code written for the project’s needs. The difference lies not in speed or quality but in whose code the work is handed over to, and in the maintenance cost of that handover.
The question is usually asked as “which one is better”, and in that form it has no answer. The meaningful question is this: which of the jobs the site needs are you handing over to a ready-made system, and where do you pay the cost of that handover? WordPress brings an admin panel, user management, content types and a large plugin ecosystem ready to use; its cost is a software stack that has to be kept updated. Custom development writes only what is needed; its cost is that everything has to be written and maintained.
What should the decision be based on?
Two questions settle most of the decision: how often, and by whom, does the content change, and against which criteria will the site be accepted? For a publication where several editors enter content every day, WordPress’s panel is a real gain. For a corporate site that changes rarely, publishes in several languages and has its speed and accessibility accepted by the numbers, having little code running in production is worth more. The same question is asked one layer down as well: static site or content management system.
What was used on this site and in the case studies?
This site does not use a content management system: the content lives in files and the site’s own generator renders the pages at build time. Why it is like this, and what it costs, is broken down in the comparison Astro or your own generator. In the Mikro Yazılım Destek case, by contrast, the site was built with Astro, a ready-made static site framework — so custom development is not a single path either; there is also a choice between a ready-made framework and entirely your own code.
We also measured the cost of dependencies on our own site: when we removed the two libraries we used for scrolling and left the job to the browser’s own CSS feature, the page’s JavaScript weight dropped from 51.1 KB to 33.5 KB (details). Adding a plugin or library is easy; the weight and maintenance of each one stays with the site for years.
What did we not measure?
We have not systematically measured the speed or accessibility of sites built with WordPress; so we do not give a general verdict such as “WordPress sites are slow” or “custom development is faster”. The table above describes the structure of the two approaches; a site’s real speed is learned by measuring that site itself. Whichever approach is chosen, the acceptance criterion needs to be written into the proposal — in corporate web design projects we write this criterion as the value measured with real users.
If you want to see these answers on your own site, corporate web design delivers design, code and technical SEO from one hand, on a measurable budget.
Criterion
WordPress
Getting started The installation is ready; goes live quickly with themes and plugins
Content editing Admin panel; a familiar interface for non-technical editors
Runtime environment Requires PHP and a database (MySQL or MariaDB)
Update load Core, themes and plugins are updated separately; minor and security releases in the background, major releases with approval
Custom development
Getting started Every component is written; getting started takes longer
Content editing Set up per project: a panel, files or a separate content service
Runtime environment Depends on the choice: static file hosting or a server application
Update load Only the dependencies used in the project; static output has no code running in production
WordPress
Adding functions Large plugin ecosystem; if the need is not covered by a plugin, a plugin is written
Performance Depends on theme, number of plugins, hosting and caching; a well-built installation can be fast
Handover Widespread; many developers know it
Where it fits An editorial team publishing frequently, standard needs, work that calls for ready-made functions
Custom development
Adding functions Every function is written in code; no limit, and the cost sits in the project
Performance Depends on the code written; a budget can be set at the start and kept
Handover Project-specific; handover depends on written documentation and the readability of the code
Where it fits Measurable delivery, unusual requirements, long-lived and auditable output
FREQUENTLY ASKED QUESTIONS
Are WordPress sites slow?
Not by design. A WordPress site’s speed is determined by its theme, number of plugins, hosting and caching; a well-built WordPress site can be fast. We have no measurements of our own on the speed of WordPress sites for this comparison, so we do not give a general verdict.
Who will update a custom-developed site?
The answer should be written in the proposal. In custom development the content workflow is set up per project: a panel, a content service or plain files. On this site the content lives in files and the site is regenerated with a single command; if your team has no developer, who will handle updates is discussed separately.
What is lost when moving from WordPress to custom development?
If the addresses are not preserved, the visibility the old addresses have built up in search engines. That is why, in a migration, a list of old addresses is drawn up and each one is permanently redirected to its new equivalent; the content is also exported and moved into the new structure.