WordPress vs Custom Site: The 10-Minute Decision Test
Two quotes for the same job, and they describe two different products. One says WordPress and hands you a login; one says custom site and hands you a launch date. Most owners arrive here after typing “wordpress vs custom site” into a search bar, and the real decision is not taste or budget: it is who keeps the site correct for the next three years. This piece settles it with numbers, most measured on our own builds this week.
One question decides this, not a feature table
Every enquiry we take starts the same way: the owner has collected quotes and cannot compare them, because one is a product and one is a project. Before any code, our discovery process ends with a technology stack recommendation, and it answers exactly one question. Is an administrator login enough to run the job the site has to do? If yes, WordPress deserves a serious look. If the site itself has to do the job, like booking real slots, publishing listings that expire, or scoring a quote request, a login changes nothing. That single answer moves everything else: the hosting, the budget, the maintenance, and who you call when it breaks.
WordPress, in the words of its own documentation
WordPress is not a mystery product; it documents itself. The requirements page (checked 24 September 2026) asks for PHP 8.3 or newer, MariaDB 10.11 or MySQL 8.0, and HTTPS. The same page still supports running on PHP 7.4, while warning verbatim that older branches “have reached their official End Of Life and may expose your site to security vulnerabilities.” That gap between runs and supported is where small businesses quietly live: a host keeps an old PHP version one click away, the site keeps working, and nobody is paid to read the security feeds. The platform is honest about this gap; the sales pages usually are not.
The maintenance week we just watched
Anyone selling “set it and forget it” for WordPress is describing a product that does not exist. While researching this piece, the release archive showed four patch releases inside one week: 7.1.1 and 7.0.5 on 17 September, then 7.1.2 and 7.0.6 on 22 September. Two of those were superseded within days, because the archive states only the most recent release in a series stays maintained. W3Techs data dated 23 September 2026 shows why the risk lands on small businesses: 30.4 percent of WordPress sites still run version 6, and 7.2 percent run version 5 or older. One in three WordPress sites is carrying a version the project itself will not defend anymore. Patching is not optional; it is the weekly bill for the free product, and it is always due to someone: you, your agency, or your nephew.
What we ship instead, in bytes
On 24 September 2026 we measured the HTML of our three public builds. mtufaildiagnosticcenter.com delivers its homepage in 2.8 KB on the wire. warasat.com.pk sends 11.9 KB of HTML, one first-party JavaScript file, and a reCAPTCHA loader. www.truckaxic.com (Next.js) sends 16.8 KB of HTML with 22 references into its own static asset tree. None of the three contains a single WordPress fingerprint: no wp-content, wp-includes, wp-json, or /wp-admin anywhere. You can run the same check in one line of bash. This is the line we ran against warasat.com.pk:
curl -s https://warasat.com.pk/ | grep -o "wp-content\|wp-includes\|wp-json\|/wp-admin" | wc -lZero means custom or at least headless. A big number means WordPress, and tells you which door the maintenance bill comes through. We are not claiming a page-weight victory over WordPress in general; we never measured WordPress sites for this piece. What the zero tells you is structural: nothing on these pages exists because a plugin needed it.
Where WordPress is the right answer
This is where most comparisons turn into adverts, so let us be precise. WordPress powers 58.8 percent of sites with a known CMS and 40.2 percent of all websites (W3Techs, 23 September 2026). When the job is publishing text and images to an audience that reads and replies by email or phone, WordPress is the shortest path to done. A five-page clinic profile, a restaurant menu, a freelancer portfolio: an administrator edits it, the updates ship tonight, and no developer is on the critical path. W3Techs also shows Elementor in use on 31.5 percent of WordPress sites and WPBakery on 7.4 percent, so the ecosystem has absorbed the “who designs it” question. Our own discovery works the same way: the stack recommendation picks the fewest moving parts that satisfy the requirements, and twice this year that answer has pointed away from us, toward WordPress. We said so and recommended it; we do not bill for a login page.
When the site is the product, custom wins
The moment the site has to do the business, not just describe it, the calculus inverts. Our diagnostic-centre build is the clean case. Appointment reminders exist because patients forget appointments: Curogram’s guide (updated 22 July 2026) puts the average no-show rate at 5 to 8 percent, with some specialties above 30 percent and each missed visit costing roughly $200 in lost revenue. A page-builder form cannot refuse a double-booking; a small custom application can refuse it, and refusing it is the feature. The same logic runs through our other builds. warasat.com.pk carries live listings with expiry, so an agent never shows a sold plot; it caches its list images on the fly at 800 pixels wide, so new photos need no designer. truckaxic.com turns a quote request into a scored, routed workflow; we cut its form from 11 fields to 4, and wrote what that did for enquiries. None of those behaviours comes from a plugin box. Each was written against one requirement, which is also why nothing in the code is there “just in case”.
WordPress vs custom site: the ten-minute test
You can settle your own case before lunch. Write down the one job your site must do beyond showing information and collecting messages. Then run this check on any site you own or were quoted, and against any developer’s demo:
| Your requirement | What usually fits | The catch |
|---|---|---|
| Brochure site, edited by the owner | WordPress | You own the update routine, weekly, forever |
| Catalogue or portfolio, rare edits | Either, honestly | Count the plugins before you compare prices |
| Bookings against real slots | Custom | Page-builder forms do not refuse double-booking |
| Listings that expire, scored quotes, workflows | Custom | Maintenance contract for the app, not for plugins |
| Content someone else must edit later | WordPress | Hand over a manual, not a login |
If every row lands in the WordPress column, you have a cheap decision, not a hard one, and you should take it.
Who owns the updates
Whichever way you go, somebody must own the update routine, in writing. On the WordPress path that means plugin updates, PHP version bumps and backups on a schedule, or the site quietly becomes one of the 30.4 percent stuck on version 6. We run our own maintenance loop for clients the same way we run deploys: test, ship, verify, report. Our maintenance and support service exists for exactly this, and we also described the backup routine most owners skip. On the custom path the ownership question does not disappear; it changes shape. Fewer components, so fewer surprise updates, but the application itself is yours: dependency bumps, security patches for the stack, and a team that can read its own code. On both paths, the honest question to a vendor is the same one: who applies the patch, how fast, and how do I verify it happened?
If you are choosing this week
Skip the feature table entirely. Write the one job sentence, run the byte-and-fingerprints check, ask your vendor the ten-minute-test questions, and pick the honest answer. If the honest answer is WordPress, we will tell you, because our discovery is built to recommend the fewest moving parts, not the largest invoice. If it is custom, our web development service runs fixed scope, weekly demos, and an MVP cycle of 6 to 10 weeks, and you can book a free consultation to put your one job sentence in front of us.
FAQ
Is WordPress cheaper than a custom site?
Usually at launch, clearly, because templates and plugins already exist. The comparison that matters is over three years: add hosting, plugin licences, update labour and the eventual redesign against a custom build’s maintenance contract. We have watched owners pay for speed at launch and then pay monthly for stability; we have also seen WordPress stay the right answer for years on a brochure site. Compare three-year totals on your actual requirement, and the decision usually makes itself.
Can I move from WordPress to a custom site later?
Yes, and it is normal, not a failure. Your content, your domain and your SEO history all survive the move with redirects and an export. What does not survive automatically is behaviour: if you outgrow WordPress because you need real booking logic or scored quote workflows, that logic has to be built new. Plan the migration on a quiet week, keep the old site live until redirects are tested, and expect the design phase to take longer than the code.
Do you build WordPress sites?
Not as our main service, and we say so during discovery. Dev2Production builds custom web and mobile software, AI agents, and the infrastructure around them. When discovery says WordPress is the right answer for a client, we recommend WordPress and help them choose it well, because the worst outcome for both sides is us selling a custom build where an administrator login would do. Our three public builds, including warasat.com.pk, are custom, and that is a selection effect, not an accident.
How long does a custom site take?
Our simple custom sites run about 6 to 8 weeks, and our full MVP cycle runs 6 to 10 weeks with a 10-week maximum, fixed scope and weekly demos. Discovery ends with a technology stack recommendation, which is where the WordPress-versus-custom question gets answered for your case. If your requirement lands in the WordPress column of the ten-minute test, the honest timeline is shorter than ours, and a template path may serve you better.
How do I check what a site is built with?
View the page source in your browser and search for wp-content or wp-includes: hits mean WordPress. For a faster check, run the one-line curl and grep from the section above and count the fingerprints; zero means custom or headless. View-source tells you the platform, not the quality: plenty of beautiful WordPress sites load slowly, and plenty of custom sites are worse. Check performance separately, ideally on mobile data.