WordPress or a custom website: decide from the publishing workflow
Compare WordPress, static websites and custom applications through real project requirements, ownership, publishing access and maintenance.
WordPress and custom development are not opposites. A WordPress website can have a custom theme and tailored publishing tools. A Next.js website can use an off-the-shelf design or an external content management system. The useful question is what the site must let visitors and editors do.
Start with who changes the content
If several people need to publish articles, upload images and review drafts, include that workflow in the brief. WordPress provides roles and capabilities that can be assigned to different users; the official documentation explains the permissions available. The interface and roles still need to be configured for the actual organisation.
If a small brochure site changes only occasionally and the owner prefers managed updates, a static implementation may be sufficient. Do not add an administration system simply because websites usually have one. Equally, do not require an owner to edit source code if independent publishing is a core requirement.
Three examples from my work
MAHVU uses a custom WordPress theme and a front-end publishing form designed for blind association members. The important requirement was a usable publishing journey. The project included tests with screen readers and members; choosing a CMS did not remove the need for that work.
Sanegon followed a different path: an initial intervention on WordPress, then a static Next.js rebuild without a database or administration area. The documented scope focused on the presentation, content structure and performance of a brochure site. That is a project-specific choice, not proof that every WordPress site should migrate.
LR Studios is a catalogue presenting mobile games and directing visitors to their download platforms. Its HTML, CSS and Bootstrap implementation shows that a clear public journey does not necessarily require a complex application stack.
Compare the complete scope
| Requirement | What to clarify |
|---|---|
| Independent publishing | Who creates content, who approves it and which interface they will use |
| Custom functionality | Exact business rules, external tools, accounts and data needed |
| Design | Which layouts are reusable and which genuinely need custom work |
| Search visibility | Rendered content, URLs, metadata, internal links and migration handling |
| Maintenance | Components to update, backup scope and person responsible |
| Handover | Access to domain, hosting, source, content exports and documentation |
Neither a framework name nor a CMS guarantees speed, accessibility or search rankings. Compare a representative page and task on the proposed solution, including the scripts and integrations it will actually load.
Understand the cost of the editing system
A headless architecture can separate the publishing interface from the website. It also introduces connections, previews and deployment behaviour to maintain. Ask what practical benefit justifies those moving parts for your project.
A custom administration area is a product in its own right: login, permissions, validation, error messages, backups and training need a scope. A simple public website does not automatically make its back office simple.
Before choosing, ask the provider to demonstrate a real task: “Change this service description, replace its image and preview the result before publishing.” That reveals more about day-to-day autonomy than a list of technologies.
Make the decision reviewable
Write down the chosen approach, the alternatives considered and the requirement that decided the choice. Include ongoing costs and the conditions under which a future migration might become useful.
You can prepare those requirements with the web project brief, then compare deliverables using the website quote guide. My services cover both presentation websites and more specific development needs, with the technical approach defined from the project.