What Is WordPress Development? Scope, Costs and Timelines

WordPress development is a phrase that gets used to describe a 400 USD job and a 40,000 USD job, which is why quotes for what sounds like the same website arrive two orders of magnitude apart and both parties think the other is unserious.

The gap is almost never dishonesty. It is that the buyer has not specified, and often does not know, which kind of work they are asking for. A developer quoting theme configuration and a developer quoting a custom build are answering different questions with the same brief.

This piece separates the four types, gives verified market ranges with the caveats that make them meaningful, sets out what genuinely drives cost, and lists the questions that tell you whether a quote is real. ThemesCraft builds WordPress themes, which is a disclosure rather than a pitch: the section on when you do not need custom work is where to check whether this is advice or marketing.

The four kinds of work

Type	What is actually done	Typical range	Timeline
Theme configuration	Existing theme, customiser and builder settings, your content	500 to 3,000 USD	1 to 3 weeks
Custom theme build	Bespoke design coded into a theme from a starter or framework	3,000 to 15,000 USD	4 to 10 weeks
Custom functionality	Plugins, integrations, APIs, custom post types and workflows	2,000 USD and up, highly variable	Depends entirely on scope
WooCommerce build	Any of the above plus catalogue, payments, shipping and tax	5,000 to 25,000 USD and up	6 to 14 weeks
Ongoing maintenance	Updates, backups, security, monitoring, small changes	50 to 2,500 USD per month	Continuous

That maintenance row spans fifty times its own floor, and the spread is real rather than sloppy. Fifty dollars a month buys automated updates and a backup. Two thousand buys a named person, a staging workflow, performance monitoring and an agreed response time. Both are legitimately called maintenance.

Theme configuration versus custom build

This is the decision that sets your budget, and most people make it backwards, starting from a price and discovering what it buys.

	Theme-based	Custom
Design	Constrained by what the theme supports	Whatever was designed
Speed to launch	Weeks	Months
Performance	Depends on the theme. Often heavier than needed	Only loads what you use
Ongoing cost	Theme licence, plus keeping up with its updates	Developer time when something needs changing
Who can change it later	Almost anyone familiar with that theme	Someone who can read the code
Risk	Theme is abandoned and you have to migrate	Developer disappears and nobody understands it

The honest position: most small business websites do not need a custom theme. A well-chosen theme, configured properly, with good content and real photography, outperforms a mediocre custom build at a fraction of the price. Custom is worth paying for when the design is a genuine differentiator, when performance requirements are strict, when you need functionality no plugin provides, or when the site is large enough that a generic theme’s assumptions start costing you.

What actually drives the price

Not page count, which is what most briefs lead with. Six things move a quote materially, roughly in order.

1. Unique page templates. Forty pages using four templates is a small job. Eight pages each needing its own layout is a larger one. Count templates, not pages.
2. Integrations. Every external system, CRM, payment gateway, booking engine, ERP, is a separate piece of work with its own failure modes and its own testing. This is where fixed-price quotes most often go wrong.
3. Content migration. Moving 40 pages by hand is an afternoon. Moving 4,000 posts with images, redirects and preserved URLs is a project with its own scripts and its own QA.
4. Who supplies the design. A finished design in Figma is a different engagement from asking a developer to also be the designer. Two skills, two rates.
5. Custom back-end functionality. Anything WordPress and its plugin ecosystem cannot do out of the box is bespoke software, priced and scheduled as such.
6. Revision rounds. Unlimited revisions in a proposal means either the price includes a large buffer or the scope will be disputed later. Two named rounds is healthier for both sides.

Agency, freelancer or in-house

	Agency	Freelancer	In-house
Cost	Highest	Lower	Highest over time
Covers design, dev, content, QA	Yes	Usually one or two of them	Depends who you hire
Continuity if one person leaves	Yes	No. This is the main risk	No
Speed for small changes after launch	Slower, ticketed	Fast, if they are available	Fastest
Best when	Complex build, multiple disciplines, you need a process	Clear scope, one skill set, budget matters	The site is core to how the business operates

A middle path that works well: a freelancer for the build, and a separate maintenance arrangement with a different provider. The build is a defined project with an end; maintenance is indefinite and needs continuity. Buying them from the same person couples two risks that do not have to be coupled.

Questions that separate real quotes from optimistic ones

• Is this a custom theme or a commercial theme configured? If it is commercial, which one, and who pays the annual licence from year two.
• Which page builder or framework, and what happens if I deactivate it? The answer tells you exactly how portable your content will be.
• Who owns the code at the end? Should be you, in writing. Some agencies retain ownership and licence it, which is legitimate if disclosed and unpleasant to discover later.
• Is there a staging environment, and will I see the site before launch? No staging means updates get tested on your live site forever.
• Are redirects from the old URLs included? The single most common post-launch disaster is a redesign that drops every existing URL and takes the search traffic with it.
• What happens after launch, and at what rate? Get the hourly or retainer figure before you sign, not when you need a change.
• Can I see two sites you built that are still live? Still live is the operative phrase. Run them through a page speed test yourself.

What maintenance should actually include

Maintenance is where the recurring money goes and the least specified item in most contracts. A plan worth paying for names these:

• Updates applied on staging first, not straight to production. This is the difference between maintenance and automation.
• Off-site backups with a stated retention period, and a restore tested at least annually.
• Uptime monitoring with a defined response time. Monitoring that emails somebody who reads it on Monday is not monitoring.
• Security scanning and a stated incident procedure. Who does what, and at whose cost, when the site is compromised.
• A named allowance of content changes, in hours per month, so small requests do not become invoices or arguments.

A plan that says updates and backups for 99 dollars a month and nothing else is probably an automated script. That may be fine for a brochure site. It is not adequate for anything that takes payments.

When you do not need any of this

Three cases where commissioning WordPress development is the wrong call, written by a company that sells WordPress work.

• Your current site works and the real problem is the content. Rewriting the copy and replacing stock photography costs a fraction of a rebuild and usually moves the metrics further.
• You need five pages that will never change. A theme configured over a weekend, or a simple builder, is sufficient. Do not buy a bespoke system to serve a brochure.
• Nobody will own the site afterwards. An unmaintained custom site is worse than a maintained generic one. If there is no budget for maintenance, spend less on the build and keep the difference for updates.

If you are choosing tooling rather than a vendor, our breakdown of WordPress development frameworks covers what your developer is actually deciding between, and what WordPress is covers the platform itself if you are earlier in the process than this article assumes.

Frequently asked questions