"Should we build this on WordPress or have it built properly?" is one of the most common questions we get from teams in Singapore, Kuala Lumpur and across Southeast Asia — and it is almost always framed as a question about quality. It isn't. WordPress runs a substantial share of the web, including sites with serious traffic and serious revenue behind them. The real question is about the shape of what you are building and who has to maintain it after launch.
Here is the decision as we actually make it with clients, rather than the version agencies give you based on what they prefer to build.
The test that settles it in ten minutes
Ask one question: is the site mostly publishing content, or mostly running a process?
Publishing means pages, posts, product listings, landing pages, case studies, careers listings — content that editors create, arrange and retire. The system's job is to make that easy and get it in front of search engines quickly.
Running a process means a user logs in and something happens to data: an application is assessed, an order routes through approvals, a claim is scored, inventory moves between locations, a price is calculated from rules that change quarterly. The content is incidental; the logic is the product.
If it is publishing, WordPress is usually the right answer, and the argument against it is rarely technical. If it is a process, a custom build is usually cheaper over three years even though it costs more in month one — because every piece of process logic you bolt onto a CMS through plugins becomes something you cannot upgrade, test, or reason about.
Where WordPress genuinely wins
Editorial velocity
A marketing team that can publish without a developer will out-publish a team that files tickets, every single time. If your growth plan depends on shipping landing pages and articles weekly, the CMS is not a compromise — it is the strategy. A custom build that requires engineering for every page change quietly caps your content output at whatever your sprint capacity allows.
Hiring and handover
You can hire someone in Singapore, Kuala Lumpur, Dubai, or almost anywhere to maintain a conventionally built WordPress site. That matters more than teams expect. A bespoke stack with three contributors who have all since left is a liability that shows up two years after the invoice.
Time to first revenue
For a marketing site, a WordPress build reaches production in weeks rather than months. If the site's job is to generate leads, the months you don't spend building are months of pipeline you don't lose.
Where WordPress quietly becomes expensive
Plugin-stacked business logic
The failure pattern is consistent: a membership plugin, a forms plugin, a payments plugin, a workflow plugin, and four small snippets in the theme that connect them. Nothing is individually unreasonable. Together they form an application nobody can test, with an upgrade path that breaks whenever any one vendor ships a major version. Teams in this position are usually paying more in maintenance and emergency fixes than a custom build would have cost to run.
Multi-tenant or permissioned data
The moment different users must see different subsets of data — distributors seeing only their region, clients seeing only their own records — you are building an application with an authorisation model. The WordPress role system was not designed for that, and the plugins that extend it are where a large share of the findings in our penetration tests of WordPress estates originate.
Integration depth
One-way form-to-CRM handoffs are fine. Bidirectional sync with an ERP, real-time inventory from a warehouse system, or a pricing engine that has to answer in milliseconds are not CMS problems. They are integration problems, and they belong in a service you control.
Performance under editorial freedom
Page builders that let anyone drag anything onto a page are the same page builders that let anyone put four megabytes of uncompressed hero imagery above the fold. If Core Web Vitals matter to your search performance — and in competitive markets they do — you need either build-time discipline or a component set that makes the slow thing impossible.
The hybrid that works
For most of the teams we work with, the answer is not one or the other. It is WordPress for the marketing surface — pages, articles, case studies, careers — and a separate application for the product, sharing a design system and a domain so visitors never see the seam.
This keeps marketing fast and independent while the application stays testable and properly owned. It also makes the eventual decision to replace either half a contained project rather than a rebuild.
The one thing to get right is where content ends and product begins. Draw that line deliberately at the start, write it down, and defend it — because the slow drift of product features into the CMS is exactly how the plugin-stack problem starts.
What to ask a vendor before you commit
- Which parts of this are plugins, and who maintains each one? Ask for the list before contract, not after. Check the last update date and whether a commercial licence is required — and who pays for it in year two.
- What happens on a major core version? A vendor who has done this before will describe a staging process and a rollback. A vendor who has not will say it is automatic.
- Can editors break the layout? The honest answer is "yes, unless we constrain the blocks" — and constraining them is work that should be in the quote.
- Where does the business logic live? If any answer involves a code snippet in the theme, that logic has no tests and will not survive a redesign.
- What does the hosting actually run? Object caching, a CDN, a current PHP version, and a backup you have personally restored once. Shared hosting with a caching plugin is not a production setup for a site that carries revenue.
A reasonable default
If your site publishes content and captures leads, build it on WordPress, constrain the block set, host it properly, and spend the savings on content. If your site authenticates users and makes decisions about their data, build that part as an application from the start — migrating away from a CMS later is always more expensive than the head start it bought you.
We do both, and we will tell you which one your project is before you sign anything. See how we approach WordPress development and custom software development, or read our guide to estimating development costs before you request quotes.