· 9 min read · Wwwebtech Team

WordPress or Custom Build: An Honest Decision Rule

Neither wins by default. Decide on three things — who maintains it, how often it changes, and what it must connect to — and the answer usually picks itself.

Most of the argument about WordPress versus a custom-built website is fought by people selling one of them. The developer who writes React all day will tell you WordPress is a security liability. The agency with fifteen WordPress sites under maintenance will tell you custom builds are a trap you cannot escape. Both are describing their own convenience, not your business.

There is a genuine decision here, and it is not really a technology decision. It is a decision about who will look after this thing for the next four years. Get that question right and the technology follows.

What the two words actually mean

WordPress is a content management system, or CMS — software that sits on your web server and lets a non-technical person add pages, change text and upload images through a browser login, without touching code. It is free, open source software. What you pay for is hosting, a theme (the design), plugins (add-on features), and the person who assembles and maintains it all.

A "custom build" is less well defined, which is part of the problem. It can mean anything from a hand-coded set of HTML pages to a full application built on a framework like Laravel, Django or Next.js, with a database and an admin panel written specifically for you. Sometimes it includes a headless CMS — a content system that stores your text and images but leaves the front end entirely to the developer. When someone quotes you for a custom site, ask precisely which of these they mean, because the maintenance implications are wildly different.

The important distinction is not "one is a template and one is bespoke". A well-built WordPress site can have a completely bespoke design and custom functionality. The distinction is who wrote the code you depend on, and who can be paid to fix it later.

The three questions that decide it

1. Who maintains it, in practice, on a Tuesday afternoon?

Not who you hope will maintain it. Who actually will.

If the honest answer is "my marketing executive, or my son who is good with computers, or me at eleven at night" — that points hard at WordPress. The whole point of a mature CMS is that a reasonably confident person can add a page, swap a hero image, or publish a blog post without a developer in the loop. The interface is familiar to anyone who has used it before, and there are thousands of people in Delhi alone who can pick up an existing WordPress site.

If the honest answer is "we have a retained development partner and a monthly budget for it", custom becomes viable. Custom code does not maintain itself either — it needs framework updates, dependency patches and server care — but that work goes to a professional rather than landing on your operations manager.

The failure case is obvious once you name it: a custom-built site handed to a business with no development retainer. Two years later the developer has moved to Bengaluru, nobody knows how the admin panel works, and a text change on the pricing page needs a quote. We have seen more businesses trapped this way than by any plugin vulnerability.

2. How often does the content actually change?

Be honest here too. Many businesses commission a blog and publish four posts.

If your site is nine pages that will read almost the same in three years, the CMS is largely wasted weight. You are running a database, a PHP application and a plugin stack to serve content that could be static files. There is nothing wrong with that — it works fine — but it is not an argument for WordPress either.

If you publish weekly, run seasonal offers, add case studies, list new products, or update prices — WordPress earns its keep every single week. The alternative is a queue of small change requests sitting in someone's inbox, and that queue is where marketing momentum goes to die.

3. What does it have to connect to?

This is the question that most often overturns the first two.

If the website is essentially a brochure with a contact form, integration is not a factor. If the website is the operation — a booking system that must respect real inventory, a dealer portal, a quoting engine that pulls live rates, a dashboard your field staff log into — you are not building a website. You are building software with a website attached, and that is custom territory whether or not WordPress is somewhere in the picture.

The middle ground is large and it is where most Indian SMEs actually sit: a content site that needs to talk to Razorpay or a payment gateway, push enquiries into a CRM, fire a WhatsApp notification, sync stock with Tally or Zoho, and post to a Google Business Profile. Nearly all of that has a well-trodden WordPress path. Where it gets ugly is when you need three of those talking to each other with conditional logic, at which point a plugin pile becomes fragile and you are better off putting the logic in a proper automation layer outside the website.

Where WordPress genuinely wins

Setting aside cost for a moment, there are three advantages that are real and that custom builds struggle to match.

Replaceability of the person, not just the code. This is the big one and it is rarely stated plainly. If your agency relationship ends badly, a WordPress site can be handed to almost anyone. A Laravel application built to one developer's private conventions can take weeks for a new team just to understand. You are buying an exit route.

Ecosystem for boring but essential things. Multilingual content, structured data markup, XML sitemaps, redirect management, form spam filtering, GDPR and cookie notices, staging environments, scheduled backups. On WordPress these are solved problems with mature tools. On a custom build each one is a line item someone has to write, and quite often the quote quietly omits several of them.

Editorial velocity. If content is central to how you get found — and for most service businesses it is — the difference between publishing in ten minutes and raising a ticket is enormous over a year. Our own view on search visibility is that consistency beats cleverness, and consistency needs a low-friction publishing tool.

What we would not buy in either camp

A few things sold routinely in this category that we think are bad value.

  • A ₹3,000 multipurpose theme with a page builder as the foundation of a business site. These themes ship with dozens of features you will never use, load enormous CSS and JavaScript files, and lock your content into shortcodes that break the day you switch theme. They demo beautifully. They perform badly, and Google's Core Web Vitals thresholds — Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1 — are hard to meet when your homepage ships a megabyte of unused script.
  • "Custom" that is a bare CMS with no editor training. If a custom admin panel is delivered without documentation and a walkthrough recording, it is not finished.
  • Plugin counts as a selling point. "Includes 40 premium plugins worth ₹80,000" is a warning, not a benefit. Every plugin is code from a stranger with access to your database, and every one needs updating.
  • Rebuilding a working site because the technology is unfashionable. An agency proposing to move a perfectly functional WordPress site to a modern JavaScript framework, with no change in what the site does for customers, is proposing a cost with no business case. Ask what a customer will be able to do afterwards that they cannot do now. If there is no answer, do not spend the money.
  • Lifetime hosting for a one-time fee. Nobody funds a server for your lifetime out of one payment. Either the price is padded or the service will quietly degrade.

A rule you can apply today

Write down three answers.

  1. Name the person who will change the website next month. If they are not a developer, WordPress unless something forces otherwise.
  2. Count content changes per month over the last year, honestly. Under one, the CMS barely matters. Over four, editorial ease should dominate the decision.
  3. List the systems the site must read from or write to, and mark which need to happen in real time. If two or more need real-time, two-way data, get a custom assessment before committing to a plugin route.

A rough shape of where that lands most businesses:

SituationUsually the right call
Service business, 8–20 pages, blog, enquiry formsWordPress, lean theme, few plugins
Retail with 50–500 products, standard checkoutWooCommerce or a hosted ecommerce platform
Content-heavy site, several authors, multiple languagesWordPress
Booking or inventory logic specific to your operationCustom application, marketing site possibly separate
Customer or dealer logs in and sees their own dataCustom, or a CRM with a portal
Five static pages, no publishing plansEither; choose on maintenance cost, not features

One genuinely useful hybrid deserves a mention: keep the public marketing site on WordPress so your team can publish freely, and build the transactional part — the portal, the calculator, the booking engine — as a separate application on a subdomain. Two smaller, clearer things beat one large tangled thing more often than developers admit.

The part nobody can be sure about

How AI assistants and AI-generated search results will treat websites over the next few years is genuinely unsettled, and anyone giving you a confident answer is guessing. What seems reasonably safe to say is that clean, server-rendered HTML with clear headings and structured data is easier for any automated reader to parse than content assembled by JavaScript in the browser. That is an argument for good engineering, not for a particular platform — a well-built WordPress site and a well-built custom site both clear that bar, and a badly built one of either does not. If this matters to you, our page on AI visibility sets out what is observable today and what is still speculation.

What to do next

Before you take any quote, answer the three questions in writing: who maintains it, how often it changes, what it must integrate with. Then send those three answers to whoever is quoting and ask them to justify their recommendation against them specifically. A good partner will sometimes talk you out of the more expensive option; that is the signal you are looking for.

If you want a second opinion on a build you have been quoted for, or on a site you already own and are unsure about, get in touch with those three answers to hand. You can also read more about how we approach website builds and what we include as standard.

Questions we get asked

Is WordPress secure enough for a business website?

WordPress core is actively maintained and patched. Most compromises trace back to outdated plugins, abandoned themes, or weak admin passwords rather than the core software itself. If you keep the plugin count small, apply updates promptly, enforce strong passwords with two-factor authentication and take regular off-server backups, it is a reasonable platform for a business site. If nobody is going to do those things, no platform will save you.

Will a custom-built site rank better on Google than WordPress?

Not because of the platform. Google evaluates the pages it receives — content, crawlability, page speed, mobile behaviour, links — not the software that produced them. A fast, well-structured WordPress site will out-rank a slow custom build, and the reverse is equally true. Anyone promising better rankings purely from a technology change is selling you the wrong thing.

Can I move from WordPress to a custom site later, or the other way?

Yes, and content migration is usually the easy part since WordPress exports cleanly and most databases can be mapped. The real cost is redirects, design rework and re-testing every form and integration. Plan URL-for-URL redirects with 301 status codes before launch, or you will lose search rankings you spent years earning.

How many plugins is too many on a WordPress site?

There is no fixed number, but every plugin is third-party code with database access that needs updating. A useful test is whether you can name what each one does and why it is there. If a plugin duplicates something your theme or another plugin already handles, or you cannot explain it, remove it and test.

We only need five pages. Do we even need a CMS?

Probably not for the content itself, but think a year ahead. If you may add a blog, case studies or landing pages for campaigns, a lightweight CMS saves you paying for changes later. If the pages genuinely will not change, choose on hosting cost and how easily someone else can take over.

If this is your problem

What we’d actually do about it.

All posts

Start here

Want us to look at yours?

Send the URL and what you think is wrong. We’ll tell you what we see, whether or not you hire us. Reply within 1 business day.

What do you need?

We reply within 1 business day. No newsletter, no sales sequence.