WordPress

Quoting WordPress Work at a Fixed Price So the Number Holds

How to scope a WordPress project so a fixed quote survives reality: discovery first, what the quote must state, the change process, and how to price risk.

5 min read
WordPressPricingProcess
932 words5 min read

Why fixed quotes go wrong

Every developer has quoted a WordPress job at a fixed price and lost money on it. The reason is almost never that the work took longer than estimated. It is that the work turned out to be different from what was estimated: the "small" form had eleven conditional fields, the "existing" theme was a decade-old page builder, the "just move it" migration involved a store with four thousand products.

A fixed price is a promise about a defined thing. Most fixed-price failures are failures of definition, not of estimation. So the method is mostly about defining.

Discovery before the number

We do not quote a fixed price for anything on an existing site without seeing it. For new builds, not without a written page list and a content plan. The discovery step is short and it is not optional:

For existing sites: admin access, a look at the theme and plugin list, the hosting, the PHP version, Query Monitor on a couple of pages, and the error log. Half an hour to two hours. It answers: is this a sound site with a bounded task, or a fragile site where any change is an excavation? The quote is different for each, and sometimes the honest quote is "fix the foundations first, separately".

For new builds: the page list, the content model (what are the repeating things: services, staff, locations), where content comes from and when, the integrations (booking, payments, CRM, email), the design source (ours, theirs, a template), and the hosting. An hour's call plus a written summary the client confirms.

If a client will not do discovery, quote hourly or decline. A fixed price without discovery is a guess with your margin attached.

What the quote states

The document is the scope. It has to be specific enough that "is this included?" has an answer without a negotiation.

Deliverables, enumerated. Not "a website" but: these pages, these post types with these fields, this booking integration with this tool, these forms with these fields going to this address, this many rounds of design revision. A list, not a paragraph.

Assumptions. Content supplied by the client by a date, in a stated form. Hosting of a stated kind. A stated number of stakeholders giving feedback. Third-party tools that exist and work as documented. Every assumption is a thing that, if untrue, changes the price, and stating it makes that legitimate rather than a dispute.

Exclusions, explicitly. Copywriting, photography, logo design, migration of content beyond X pages, fixing pre-existing problems discovered mid-project, SEO beyond on-page basics, ongoing maintenance. The exclusions are where fixed quotes are protected. Put them in writing even when they seem obvious.

The change process. "Changes to scope are quoted separately before work begins" in one sentence, plus how small changes are handled (a small contingency of hours, or a per-item rate). This turns the mid-project "can you also just" from a margin leak into a normal conversation.

Timeline with dependencies. Two weeks from receipt of content, not two weeks from signing. The client's part is on the schedule as visibly as yours.

Payment terms. A deposit, a milestone, a final payment on launch. Fixed-price work is cash-flow work.

Pricing the risk

Some uncertainty remains after discovery. Price it deliberately:

Include contingency for the known unknowns. A plugin that might need configuration beyond the documentation. Browser testing that might turn up a layout issue. Ten to twenty percent on the estimate, not visible as a line, absorbed in the price.

Exclude the unknown unknowns. Pre-existing bugs, third-party service outages, a client's hosting that turns out to block something. These are excluded and quoted when they appear. You cannot price what you cannot see.

Price the fragility. A change on a fragile site costs more than the same change on a sound one, because of the testing and the likelihood of collateral breakage. Discovery tells you which you have. Quote accordingly, and say why: "this is higher than it would be on a maintained site because the theme has not been updated in four years and every change needs full regression testing."

Say no to fixed price when it is wrong. Exploratory debugging, "make it faster" without a defined target, ongoing tweaks, anything where the client cannot define done. These are hourly or retainer work, and pretending otherwise costs one of you.

Holding the number

The quote holds when the scope holds. When a client asks for something outside it, the answer is warm and immediate: "Yes, that's outside what we scoped; it's about X, want me to add it?" Not a fight. Not silently absorbing it. The change process in the quote is what makes this a normal sentence.

When you discover you under-estimated something inside scope, that is yours. Eat it, learn, adjust the next quote. Fixed price means fixed.

When you discover the assumptions were wrong (the content is not coming, the hosting cannot do what was needed), that is the conversation the assumptions section exists for, and it happens early, not at invoice time.

What it looks like from the client's side

A client who receives a scope document with deliverables listed, assumptions stated, exclusions clear and a change process described knows exactly what they are buying and can compare it to another quote on equal terms. It is more work to produce than a number in an email. It is also why our WordPress quotes are fixed and why they hold: the number is attached to a definition, and the definition was made before the number.

All writingHire me for this