Three-year economics
WordPress vs Custom Code: Model Both Honestly
There is no single three-year total for either option, because the answer is built from your invoices, your internal hours and the service level you actually need. WordPress can cost less, more, or about the same as custom code depending on those inputs. What this page gives you instead is the arithmetic: the same capabilities, demand and labor on both sides, with every term visible so the result can be checked rather than taken on trust.
Platform and commercial references checked October 8, 2026.
Hassan Jamal·Published ·Updated ·11 min read
Before the model, here are two practitioners describing their experience of WordPress. Their opinions are context, not measured cost inputs.
Every time you load a page or post, WP wants to retrieve info from the database. While that may have made sense in the beginning, we are long since past the point where the content on pages (and posts for that matter) don't change enough to matter. WP architecture should really have switched over to treating the site cache as the primary site, with the database being treated as the backup.
u/user_number_666 · r/Wordpress · Apr 14, 2026 · 103 upvotes · Verify source
It's only when you check out some other CMS's out there (not even just the free ones) that you realise WordPress, even with its many flaws, is pretty well-rounded and user-friendly.
u/hetsteentje · r/Wordpress · Apr 15, 2026 · 9 upvotes · Verify source
The short answer
Neither option wins in the abstract, and the total is whatever your own invoices and time records say it is. That is why this page publishes formulas rather than figures: the inputs are yours, and a headline three-year total that hides them cannot be checked against your situation. Five things settle it. Our own terms, so you can check them against any quote: from $1,500 at a fixed price agreed before we start, no minimum project size, and the code, design files and accounts are yours at the end.
- ✓WordPress can cost less, more or about the same as custom code depending on the requirements and operating model.
- ✓Custom code still costs you hosting, software, dependencies, maintenance, security and support.
- ✓WordPress plugin and maintenance cost must come from the site's current invoices and work records.
- ✓Payback and lost-revenue claims require approved inputs and first-party evidence.
- ✓Choose architecture after capability and risk fit, not from a universal three-year winner.
This comparison names no three-year total for WordPress, no matching total for custom code and no period over which one repays the other. Those numbers only mean something once both options are specified against the same capabilities, demand, service level and internal labor, and a scenario that prices one side generously while treating the other as free is an argument rather than a forecast. Put your own quotes, invoices and time records into both columns, show the formula, and let anyone reading the model challenge an input.
Inputs
Invoices, quotes, labor, demand and roadmap.
Capability
Same journeys, data and operational outcomes.
Lifecycle
Dependencies, providers, releases and ownership.
Scenarios
Low, expected and high with visible formulas.
Define both options
WordPress may mean shared or managed hosting, a custom theme or builder, a set of plugins and internal or retained support. Custom code may mean Next.js or another framework with a CMS, database, search, email, analytics and hosting providers. Name the actual components, accounts, licenses and owners. Otherwise the comparison hides cost inside vague labels. For the architectural version of this comparison, see WordPress compared with Next.js and what Cloudflare built as a WordPress replacement.
Freeze a shared capability baseline
Fix what both options have to deliver before you price either one, because the misleading comparisons we get asked to referee are nearly always two quotes that were never for the same thing. Six areas make up the baseline. If a custom scope quietly drops a capability a WordPress plugin currently supplies, the lower number is not a saving, it is a smaller project.
- ✓Page templates, content types, preview, approval and localization
- ✓Forms, search, customer accounts, the store, payments and subscriptions
- ✓CRM, email, analytics, consent and operational integrations
- ✓Sign-off on search, accessibility, privacy, security and speed
- ✓Environments, monitoring, backups, recovery and response time
- ✓Repository, data, domain, provider and documentation handoff
If custom scope omits a capability currently supplied by a WordPress plugin, the lower price is not the same thing compared fairly. If WordPress includes features the business no longer needs, remove them from both scenarios.
There is no single three-year total for either option. There is only your invoices, your internal hours, and the service level you actually need.
The three-year model
Three years is the horizon where these two options separate, because a build price lands once and everything else recurs. The model carries four columns for a reason: every input needs a WordPress source, a custom source, and one rule applied identically to both. Where a figure cannot be sourced, record the assumption instead of guessing.
| Input | WordPress source | Custom source | Model rule |
|---|---|---|---|
| Initial work | Repair or rebuild quote | Discovery, build and migration quote | Same capabilities and acceptance |
| Providers | Hosting, CDN, backup and services invoices | Hosting, CMS, database, search and services quotes | Current plan and expected usage |
| Software | Theme and plugin renewals | Paid packages and provider licenses | Contracted renewal, tax and currency |
| Labor | Updates, QA, content and support hours | Releases, dependency work, content and support hours | Same fully loaded rate |
| Roadmap | Configure, extend or replace | Build or integrate | Same approved future features |
| Risk | Evidence-led contingency | Evidence-led contingency | Same method, separate risk profile |
| Exit | Export and handoff | Data, code, accounts and documentation | Include work expected within period |
Use visible formulas
The arithmetic is shown here instead of the result, because the result is yours and depends on six inputs only you hold. A three-year total published without those six terms cannot be checked by the reader, which is what makes most of the ones you will find useless. Fill these in from your own invoices and your own time records.
+ recurring providers and software
+ internal and external operating labor
+ planned roadmap changes
+ evidence-led contingency
+ exit work inside the period
Store quantity, unit cost, frequency, start date, inflation or renewal rule, source, confidence and owner for each input. A total without these fields is not an auditable model.
WordPress inputs
Six inputs make up the WordPress column and only the first arrives as an invoice. Renewals, update review, release work and recovery readiness are the lines that get left out, and each one scales with the size of the plugin list. Take them from your own contracts and your own logged hours.
- ✓Hosting, the CDN, backups, a staging site, domains and email
- ✓Theme, builder, plugin and extension renewals
- ✓Update review, staging, regression testing and releases
- ✓Content, product, user and integration operations
- ✓Work on speed, accessibility, security and being able to recover
- ✓Expected theme, runtime, plugin or workflow replacement
Two of those lines are easy to underestimate. Our notes on how plugins affect front-end performance and on diagnosing a slow WordPress site show where the hours usually go.
Collect the recurring invoices first
Start the WordPress column with what you already pay, because the real number is rarely the one people quote from memory. Pull the last twelve months of invoices and renewal notices and sort them into six groups. Work from what was billed, not from the list of installed plugins: the lines that get forgotten are the annual renewals and the support retainer that has been running since launch.
- ✓Hosting, the CDN, storage, backups, a staging site and your domain
- ✓Your theme, the page builder, and the plugins doing forms, SEO, security, caching and media
- ✓Commerce, subscriptions, bookings, memberships and payment-related extensions
- ✓Search, email sending, analytics, the consent banner, chat, monitoring, and anything wiring them together
- ✓Agency, freelancer, care-plan and emergency-support retainers
- ✓Taxes, currency, overages, seats and annual renewal changes
Public list prices can differ from what you pay on a contracted, grandfathered, promotional or usage-based plan, so the invoice wins. For every line, note who is billed, when it renews, how much of it you actually use, what depends on it, and what breaks if you cancel it.
Custom-code inputs
Six inputs make up the custom column and the build is only the first. Framework updates, provider API changes and the handoff to a future developer run for as long as the site does, which is what an optimistic custom estimate tends to leave out. Price the maintenance, not only the delivery.
- ✓Discovery, design, build, content and data migration
- ✓Hosting, bandwidth, builds, the CMS, a database and storage
- ✓Search, email, analytics, monitoring, backup and security services
- ✓Framework and package updates, QA and deployment
- ✓Custom integration maintenance and provider API changes
- ✓Documentation, repository, account and future-developer handoff
Anything on that list that goes past a marketing site sits under custom engineering, and the build variables behind the first line are unpacked in what a website costs.
A current provider may offer an allowance, but eligibility, commercial-use terms, limits and pricing can change. Use the plan that matches the business, expected usage and current terms, with a sensitivity for overage or plan movement.
Internal labor belongs in both columns
WordPress can require update and compatibility work. Custom code can require dependency, deployment and integration work. Both need content operations, access, vendor management, monitoring and recovery. Measure or sample the work using the same fully loaded labor rate.
A worked three-year model, with the numbers filled in
A method you cannot see run is hard to trust, so here is the model above with figures in it. These are constructed inputs for one scenario, not observed market ranges or a quote, and the whole point of the exercise is that you replace them with yours. The scenario: a 15-page marketing site for a small business, a CMS the team edits themselves, no ecommerce, and someone in-house spending a couple of hours a month on the site either way.
One input in that table is not a range we get to choose. A business site cannot sit on a free developer-hosting tier: Vercel's Hobby plan is restricted to non-commercial personal use, so the commercial floor is Pro at $20 a month, which is $720 across three years before any usage. We priced that in full in what Vercel actually costs. An earlier version of this table carried $0 at the low end, which contradicted our own page, so the custom column here starts at $720.
| Line | WordPress | Custom build |
|---|---|---|
| Build or setup | $500 to $3,000 | $3,500 (our Growth package) |
| Hosting, 3 years | $300 to $900 | $720 to $1,500 |
| Plugins, themes, licences, 3 years | $150 to $600 | $0 |
| Outsourced maintenance, 3 years | $0 self-managed, or $1,500 to $4,500 | $0 to $1,500 |
| Internal time, 2 hrs/month at $50 | $3,600 | $3,600 |
| Three-year total | $4,550 to $12,600 | $7,820 to $10,100 |
Two things fall out of that, and neither is the answer people expect. The ranges overlap. Over three years these are not obviously different purchases, which is why published comparisons reach opposite conclusions so easily: pick the bottom of one column and the top of the other and you can prove whichever you already believed.
The second is that the largest single line on both sides is internal time, and it is the line almost every published comparison sets to zero. A three-year total that says WordPress costs nothing to maintain is really saying somebody in your business is doing the updates, the compatibility checks and the recovery when a plugin breaks, and that their hours are free. They are not free. Put the same fully loaded rate in both columns and the comparison changes shape, which is the point made at internal labour belongs in both columns.
The custom-build input uses our $3,500 Growth package; the WordPress figures are deliberately chosen scenario assumptions so the formula can be inspected. They do not establish a market average. Replace both columns with current quotes and invoices before using the result in a decision.
Run it with your own numbers before deciding. The inputs that move the answer most are the build price, the internal hourly rate and how many hours the site really takes each month. If you have never measured that last one, it is the first thing to go and measure, because every conclusion on this page rests on it.
Security and incident scenarios
Do not claim custom code has no database, plugins or attack surface. Compare actual components, privileges, patch ownership, secret management, logging, backups and response. Base incident costs on the organization's history or an approved risk method, not a generic hack-cost average.
For incidents you've already had, write down the hours spent responding, what outside help invoiced, how long the site was down, the transactions that failed, what recovering the data took, the extra support load, any legal review and who you had to notify. Keep possible future incidents in a separately labelled contingency line. For the exposure behind that line on a WordPress site, read our review of WordPress security risk in 2026.
Performance and business effect
Measure representative routes under comparable conditions and use field Core Web Vitals where available. If performance work is released, join the affected cohorts with business events and control for other changes where possible. Do not count a public conversion statistic as the site's lost revenue or assume a framework creates the gain.
Payback and break-even
Payback is not a number anyone can hand you. It is the incremental investment divided by the annual savings you have actually verified, which means it does not exist until you have verified a saving. If your verified annual saving is zero or negative, there is no payback period to compute, and any published month number you have read was computed from someone else's inputs.
- WordPress work avoided during transition
Annual verified savings = removed direct and labor cost
- new direct and labor cost
Simple payback = incremental investment / annual verified savings
If annual verified savings are not positive, a savings-based payback does not exist. Capability, risk or strategic reasons may still justify the work. Keep those reasons separate from the financial output.
Run low, expected and high scenarios
Run four scenarios rather than one number, because a single figure hides which assumption the decision is really resting on. Low uses contracted costs, expected uses approved growth, high uses documented capacity and contingency, and stress asks what happens if a critical vendor or maintainer disappears. Apply the same confidence rules to both columns.
- ✓Low: contracted costs, stable usage and only committed roadmap work
- ✓Expected: approved growth, likely renewals and historically observed operating work
- ✓High: documented capacity, replacement and contingency assumptions
- ✓Stress: loss of a critical vendor, integration or maintainer when relevant
Do not use a pessimistic WordPress column and optimistic custom column. Apply the same confidence and evidence rules, then show which inputs change the decision.
Find the decision-sensitive inputs
Change one input at a time: traffic, content volume, internal labor rate, provider usage, maintenance hours, roadmap scope or migration price. If a small change reverses the answer, the business case is fragile and should not be marketed as a certain saving.
Non-financial decision criteria
Some of what decides this never enters the model at all. Six criteria carry weight a spreadsheet cannot hold: how fast your editors can publish, whether the workflow fits, what the regulations require, what recovery has to look like, who you can hire, and how hard it would be to leave. Weigh these alongside the number rather than after it.
- ✓Editorial usability and time to publish
- ✓Feature fit and differentiated workflows
- ✓Data control, privacy and regulatory requirements
- ✓Security, availability and recovery objectives
- ✓Hiring, vendor and internal operating capability
- ✓Portability, documentation and exit risk
The last of those deserves its own answer before the model is signed off, which we give in do you own your website.
Price three options, not two
“WordPress or custom” hides a third choice: fixing the site you have without leaving WordPress. Put all three through the same model, with the same inputs.
- ✓Maintain: keep the current build but fund it properly. Update supported software, retire unused or overlapping plugins, pay for routine QA, security, backups and incident readiness, and replace fragile integrations only where the evidence says to.
- ✓Optimize or rebuild within WordPress: a new theme or template system, a hosting change, database repair or plugin consolidation can fix measured problems while your content and editors stay where they are. Price the staging, QA, launch and retraining too.
- ✓Migrate to a custom stack: discovery, design, build, content and data migration, replacing what the plugins did, search continuity, testing, cutover and support, plus the hosting, CMS and engineering time to run it afterwards.
Page-builder debt is often what decides between the second and third options, so test it directly with how Elementor affects SEO and why Divi sites load slowly before you price a rebuild.
When WordPress may win
WordPress may be the lower-risk and lower-cost choice when the current workflows fit, maintained extensions cover required capability, the team is effective with the editor and measured problems can be repaired. Mature niche features may be expensive to reproduce responsibly.
When custom may win
Custom may fit when differentiated workflows or integration control matter, repeated platform constraints create verified operating cost, and the organization can own a software product lifecycle. Include migration, documentation, providers and long-term engineering rather than comparing only the launch build. The transition line item is broken down in WordPress migration cost and what drives migration cost, and the scope itself is described under our WordPress migration service.
PandaCodeGen as one quote input
PandaCodeGen planning tiers start at $1,500 Starter, $3,500 Growth and $5,000 Scale, with custom work scoped separately. A common payment option is 30 percent at onboarding and 70 percent on delivery. Use your written quote as the input and compare it with an equivalent WordPress option covering the same work. These starting tiers do not prove three-year savings. The tier detail sits on our pricing page, and our project work shows the kind of scope those tiers describe.
Frequently asked questions
What is the total cost of WordPress over three years?
Is a custom website cheaper than WordPress long term?
What WordPress costs should the model include?
Does WordPress cost more than Wix or Squarespace?
How should security incidents be modeled?
Is WordPress still worth it in 2026?
What is the best alternative to WordPress?
Primary sources
- WordPress maintenance documentation
- WordPress hardening guide
- WordPress export documentation
- Next.js deployment documentation
- Vercel current pricing
Compare both options from the same brief
We will scope the custom option against your actual WordPress capability, invoices and operating model, with no automatic payback claim.
Related Articles
WordPress to Next.js Migration Cost in 2026: Scope and Tiers
Price a WordPress to Next.js migration from URLs, templates, content, plugins, data, integrations, SEO, accessibility, acceptance, cutover and support.
Do WordPress Plugins Slow Your Site? A 2026 Audit Guide
Audit plugins by measured frontend, server, database, background and third-party impact. Fix the responsible work instead of treating plugin count as a speed score.
WordPress to Next.js Migration: Protecting SEO (2026)
A WordPress to Next.js migration guide covering content export, URL inventory, 301 redirect mapping, SEO preservation, staged QA, Google Search Console monitoring, and a controlled cutover.