WordPress, custom code, or a page builder? A real-world perspective

Pick the job first, the technology second

Website technology discussions often begin in the wrong place. One person recommends WordPress, another builds everything in Next.js, while someone else argues that Webflow or Framer has made both unnecessary.

That usually tells you more about the provider’s workflow than your business requirements.

Before recommending a platform, I want answers to more practical questions:

• What must the website do during its first six to twelve months?
• Is it primarily a marketing site, publishing platform, online store, or digital product?
• How often will the content change, and who will change it?
• Which integrations and workflows are essential?
• How quickly does the first version need to launch?
• Who will handle security, performance, and technical problems after launch?
• What happens if the original developer or agency becomes unavailable?
• Which parts must remain portable if you change platforms later?

Without those answers, claims about the “best platform” are usually personal preferences presented as technical certainty.

The right approach is not the one that looks most advanced in a proposal. It is the one that delivers what the business needs without creating unreasonable costs or dependencies later.

WordPress: flexible when someone takes responsibility

WordPress still suits many marketing sites, blogs, publishers, and businesses that need an established CMS non-developers can use.

It often fits when:

• editors need to create and update content without opening a support ticket for every change
• the website is content-heavy rather than application-heavy
• the project has several page types, categories, languages, or editorial workflows
• the budget favors a mature ecosystem over developing every feature from scratch
• important integrations already have stable WordPress support
• the team is familiar with the editing experience
• SEO structure and ongoing publishing matter

WordPress also has a large ecosystem of developers, documentation, and tools. That reduces the chance that only one person can understand or maintain the system.

The same flexibility can become its weakness. WordPress easily turns into a place where every new requirement is answered with another plugin.

Problems tend to appear when:

• plugins accumulate without technical governance
• several page builders or editing systems overlap
• themes and extensions stop receiving maintenance
• updates are postponed because everyone fears breaking something
• custom code is placed inside third-party themes without documentation
• similar content is built differently from page to page
• nobody owns backups, updates, testing, and recovery

WordPress is not automatically slow or insecure. A poorly constructed and neglected WordPress installation can be.

I have worked on installations with more than thirty plugins, overlapping functionality, and several visual builders affecting the same layout. They were slow, frightening to update, and expensive to repair. I have also worked with much leaner WordPress setups using a deliberate theme, structured content fields, and controlled dependencies that remained stable because someone treated maintenance as part of the project.

The difference was not the WordPress logo. It was the implementation and the ownership after launch.

Custom code: more control and more responsibility

Vue and Nuxt, React and Next.js, and other modern frameworks allow you to shape the solution closely around the product.

You can control:

• component architecture
• interface behavior
• data flows and integrations
• rendering and caching
• performance budgets
• accessibility patterns
• the design system
• testing and deployment

That control becomes valuable when the website is doing more than a conventional marketing site.

Custom development is often justified when:

• users have accounts, profiles, or personalized views
• the product includes dashboards, calculators, or complex logic
• data comes from several external systems
• the interface changes according to the user or underlying data
• the product is expected to evolve continuously
• there are unusual performance, accessibility, or security requirements
• the organization has the budget and technical capacity to maintain the codebase

The advantage is control. The cost is ongoing responsibility.

A custom project commonly needs:

• version control
• build and deployment pipelines
• staging environments
• monitoring
• dependency and security updates
• automated and manual testing
• documentation
• someone capable of understanding the architecture when it changes

Custom development is often the wrong default when:

• a straightforward marketing site must launch within weeks
• almost every requirement maps cleanly to a CMS
• the team has no plan for long-term engineering support
• content editors need significant independence
• the business is still validating its offer
• technical elegance costs more than the business value it creates

I have recommended custom development when a business genuinely outgrew its platform. I have also advised against it when a simpler system could launch sooner and validate the offer at lower risk.

Writing your own code is not automatically a sign of greater quality. Sometimes it is the right investment. Sometimes it is an expensive way to solve an ordinary problem.

Page builders are not one category

“Page builder” is often used as if all visual tools worked in the same way. They do not.

There are at least two common categories:

• builders inside a CMS, such as Elementor and Divi in WordPress
• hosted visual platforms, such as Webflow and Framer

Both offer more visual control without requiring every layout to be coded from scratch. However, they differ significantly in hosting, content modeling, plugin support, export options, ownership, and the difficulty of moving elsewhere.

That distinction matters.

An Elementor site is still a WordPress installation with WordPress hosting, a database, plugins, and software updates. A Webflow or Framer site is more directly tied to that platform’s publishing model, feature set, and pricing.

Page builders and hosted visual platforms often fit when:

• a marketing team needs to change layouts without involving a developer
• a campaign or initial version must launch quickly
• the site mostly consists of familiar content and landing-page patterns
• visual flexibility matters more than complex application logic
• the budget is limited
• a major platform change is unlikely in the near term
• the team understands and accepts the platform’s constraints

For landing pages, portfolios, campaign sites, and smaller marketing websites, that speed can have real value.

They tend to strain when:

• every section becomes a unique exception
• generated HTML, CSS, and JavaScript become unnecessarily heavy
• animations and third-party scripts are added without a performance budget
• content is copied between pages instead of being structured for reuse
• later features require more custom work than the platform handles comfortably
• licensing and platform costs rise with additional features or editors
• moving elsewhere would require substantial rebuilding
• the team assumes visual editing means technical maintenance is no longer necessary

I have seen builder-based sites perform well on Core Web Vitals because someone was disciplined about images, fonts, scripts, and component structure. I have also seen pages take many seconds to become usable because nested widgets, animations, and assets accumulated without limits.

The tool did not determine the result by itself. The implementation did.

Headless is an option, not an automatic upgrade

A common middle ground is a headless architecture: content is managed in a CMS, while a separate frontend displays it.

This can combine editorial control with a custom user experience. It may make sense when the same content serves several channels, the frontend has product-like requirements, or the organization already has technical capacity.

It also creates more moving parts:

• the CMS and frontend must be maintained separately
• previews and publishing workflows need deliberate implementation
• forms, redirects, search, and SEO metadata require planning
• editors may lose the direct visual relationship between content and page
• hosting and troubleshooting become more complex
• two systems may create two separate cost centers

Headless is therefore not automatically “modern WordPress.” It is an architectural choice that should solve a specific problem. Without that problem, it mostly adds operational complexity.

The content model matters more than the editor’s appearance

When comparing platforms, people often focus on how attractive the editing interface looks. A pleasant editor is useful, but the more important question is how the content is structured.

Imagine a company with fifty service pages. If every page is a blank visual canvas, editors can change almost anything. They can also create fifty different heading styles, CTA patterns, and content structures.

A more structured model might give every service fields for:

• primary message
• target audience
• benefits
• process
• common questions
• evidence
• CTA

That provides less freedom on each individual page but creates greater consistency, easier updates, and fewer accidental problems.

The right balance depends on the team. An experienced design and marketing team may use greater freedom responsibly. A small company without internal web expertise often benefits from clearer constraints.

The best editing system is not necessarily the one that lets you do anything. It is the one that makes common tasks easy and costly mistakes harder to make.

Ownership and the ability to change providers

Technology decisions are also control decisions.

Before the project begins, it should be clear who owns and administers:

• the domain
• DNS
• hosting
• the CMS account
• platform subscriptions
• analytics
• design files
• source code and repositories
• third-party accounts and API keys

You should also ask what can actually be moved.

The ability to export HTML does not necessarily mean the complete website can be moved with its CMS, forms, animations, search, and editing workflow intact. Access to a source-code repository is also insufficient if nobody else can install, understand, and deploy it.

A serious handover should include:

• accounts controlled by the business
• documentation of important dependencies
• publishing and recovery instructions
• licenses and recurring costs
• a clear route for another provider to take over

Vendor dependency is not always wrong. Almost every system creates some dependency. The important thing is that it is visible, reasonable, and consciously accepted.

The real cost is larger than the build quote

A cheap launch can become expensive if every small change requires specialist support. A more expensive custom system may be rational when it replaces manual work or supports a central business process.

Do not compare only the price of the first release. Also consider:

• hosting and platform subscriptions
• premium plugins and licenses
• security and version updates
• technical support
• developer time for new features
• editor time
• training and documentation
• the cost of a future migration
• the risk of rebuilding sooner than expected

A platform with a higher monthly fee may cost less overall if the team can manage more work independently. A solution without licensing fees may become more expensive when every meaningful change requires development.

The useful measure is not only the cost of construction. It is the total cost of owning, operating, and evolving the site.

Maintenance decides what works long term

Launch gets the attention. Two years later, quality becomes visible in less glamorous areas:

• security updates have been applied
• backups have been tested
• forms still work
• analytics still records the right events
• content remains current
• old campaigns and redirects have been cleaned up
• new images have not destroyed performance
• the team knows who is responsible when something breaks

Write a plain-language maintenance plan before choosing the technology:

• Who publishes and reviews content?
• Who applies and tests updates?
• Who owns backups and recovery?
• Who fixes forms, tracking, and integrations?
• Who monitors performance and accessibility?
• How is support provided, and what does it cost?
• What happens when traffic or content volume grows?

A simpler system the team can confidently manage often beats a “perfect” architecture nobody wants to touch.

What I recommend in practice

I use WordPress, visual platforms, and custom frameworks according to the brief, not because one option is morally or technically superior in every situation.

Some common starting points:

• Content-led marketing site with a small internal team: often WordPress with a lean theme, structured fields, and a limited set of deliberate plugins.
• Campaign or landing page for testing a message quickly: a visual platform can be rational if its constraints are acceptable.
• Smaller company website the marketing team wants to shape visually: Webflow, Framer, or a disciplined CMS builder may work well.
• Website with accounts, data, and advanced workflows: often a custom frontend and backend.
• SaaS marketing site and product interface sharing a design system: a custom frontend, possibly paired with a headless CMS.
• Online store: usually a mature commerce platform rather than a custom checkout built without a strong reason.

These are starting points, not universal rules.

The answer is rarely found in platform marketing or the logos on a proposal slide. It depends on who will live with the website after the project ends.

Choose for the next three years

There is no universal winner. There is only a better or worse match between objectives, budget, timeline, skills, and maintenance capacity.

Poorly maintained WordPress will lose to a well-managed builder site. Over-engineered custom code will lose to a CMS the team actually uses. A visually impressive launch that is never updated will lose to a more modest site kept fast, clear, and current.

Do not ask only which technology can build the website. Ask:

• Can the team use it confidently?
• Can another provider take over?
• Can it evolve without repeated rebuilding?
• Will the ongoing cost remain reasonable?
• Do its constraints fit the business plan?

Technology matters. How the site is used and maintained afterward usually matters even more.

Before deciding how to build your website, decide what the website needs to do for the business.

If you are unsure which approach fits your project, start a conversation. Every project has different requirements, and the right answer depends on your objectives, resources, and plans, not on whichever technology is receiving the most attention this month.