Skip to content
Choosing a web agency / pricing / contracts

How to Read a Website Proposal Like a CFO

Read a website proposal the way a CFO does: scope, exclusions, payment milestones, change rates and IP ownership. The five clauses that protect the buyer.

By WitsCode9 min read
Choosing a web agency / pricing / contracts

When most people read a website proposal they read the exciting parts: the design direction, the feature list, the timeline, the price on the cover. A CFO reads the same document the way they read any commitment of company money, looking for the unbudgeted liability before it lands. They read it for what is not on the page.

So if you want to know what to check in a website proposal, here is the short version. Check five things: the scope section, where every deliverable should be named so specifically it is almost boring; the exclusions section, where the real budget risk lives and which most buyers skip; the payment schedule, because how the money is staged tells you who the proposal protects; the change-order rate, the published cost of anything outside scope, because a proposal without one is an open cheque; and the intellectual property clause, which decides whether you will own the website you pay for or merely borrow it. The rest of this article walks each, then sets out the five clauses that, when present, mean the proposal is protecting you and not just the agency.

The price on the cover is not the cost of the project

The number on the front of a website proposal is not the cost of the project. It is the cost of the things the proposal chose to list. The actual cost is that cover price, plus everything the document quietly left out, plus every future change priced at a rate nobody has yet disclosed. This is why a proposal that looks cheap on the cover and reads vaguely in the body is so often the expensive one.

Vagueness is not generosity. It is optionality, and the side that gets to exercise it later is the agency, not you. The proposals worth signing are the specific, slightly dull ones. Remember too that a proposal often becomes the contract or is pulled into it by reference, so read it with the care you would give a contract.

Scope: read the verbs, count the templates

The scope section is where disputes are born, almost always because it was written loosely enough to mean two different things to two different people. "A five-page website" tells you very little. Which five pages? Built from how many unique templates? A twenty-page site assembled from four templates is a completely different piece of work, and a completely different price, to twenty individually designed layouts.

A scope section a CFO would accept names the exact page count, the number of unique templates behind those pages, and every third-party integration by its actual product name, whether a payment gateway, a CRM, a booking system or an email platform. It states who writes the copy and sources the images, how many revision rounds are included, the browser and device support expected, and, if accessibility matters to you, either commits to a standard such as WCAG 2.2 AA or notes it as excluded.

Read the verbs especially carefully. Design is not build. Build is not launch. Launch is not support. Each is a separate deliverable that should be priced separately, and a proposal that blurs them is hoping you will assume the later ones are free. Two traps are worth naming. "Unlimited revisions" sounds like a gift and usually functions as a trap, because an agency manages it by becoming slow until you stop asking; a fixed number of named revision rounds is healthier. The second is content. Roughly half of stalled web projects stall on content, so the proposal must say whether copywriting and image sourcing belong to the agency or to you. If it is silent, assume the work is yours, because "build" very often means an empty shell with placeholder text.

Exclusions: the section where the real money is

If a CFO reads only one section of a website proposal first, it is the exclusions section. This is the agency telling you, in writing, exactly where the future invoices will come from, and that is useful information rather than a warning sign. A proposal with no exclusions section at all is not a generous one; it means either the agency has not thought the job through, or the exclusions exist and are simply not being shown to you. Everything not explicitly included is excluded by default, and not writing it down does not make it included. It just makes it a surprise later.

The things commonly excluded are also, awkwardly, the things buyers most commonly assume are included. Copywriting and content creation. Stock photography and its licences. Logo and brand identity work. Premium plugins, theme licences and font licences, which the agency builds with and which you renew every year for as long as the site lives. Hosting and domain costs. Email setup. SEO beyond basic on-page work. Ongoing maintenance, security and updates after launch. Training. Data migration. Multi-language support. Post-launch bug fixes beyond a stated warranty window. Any one can be a fair exclusion. The danger is assuming they are inclusions when they are not.

This is also where the annual-cost trap hides. A proposal can show a clean one-time build price while the build quietly commits you to several hundred or several thousand a year in third-party licences and subscriptions. So the CFO question is not only "what does this site cost to build," it is "what does this site cost to run." Take the exclusions list, price every line, and add that total to the cover price. That sum is your true budget; the cover price was only ever the deposit on it.

Payment milestones: why fifty-fifty favours the agency

How a proposal stages the money tells you who it was written to protect. The most common structure is fifty per cent on signature and fifty per cent on launch. It is common because it is excellent for the agency's cash flow, and poor for you. You pay half before any work is visible, and the only leverage you keep is the final half, which the agency is motivated to trigger by declaring "launch" as early as it reasonably can. There is no payment checkpoint in the middle, where projects actually drift.

A milestone-tied schedule fixes this by releasing cash against delivered, inspectable work rather than against dates. A healthier structure spreads payment across recognisable stages: a deposit to start, well under fifty per cent and more typically a fifth to a third; a payment when the design is approved; a payment when the build is complete; a payment on launch; and ideally a small retention held back until a defined warranty window closes.

The principle underneath that is one a CFO never breaks: never let the cash get ahead of the delivered value. At every point you should have received value at least equal to the money you have paid, and a fifty per cent upfront payment breaks that rule on the first day. Each milestone payment should be tied to a defined deliverable you can inspect and approve, not to a date and not to the agency's word, because "payment due on completion" means nothing until "completion" is defined.

Change orders: the rate that closes the open cheque

A change order is any work you request outside the agreed scope. Scope creep is normal and not sinister; projects evolve, and asking for something new mid-build is part of real work. What matters is whether the proposal told you in advance what out-of-scope work costs.

A proposal worth signing publishes a change-order rate, a day rate or hourly rate, in writing, that applies to anything beyond scope. Without it, every change is re-quoted from scratch at the worst possible moment for you: mid-project, already committed, deposit gone. A proposal that quotes a fixed price but contains no change rate is not really a fixed price at all. It is a fixed price attached to an unfixed scope. What good looks like is a stated rate, a stated minimum billing increment such as a half-day, and a process where changes are quoted and approved in writing before any work begins. Watch, too, for asymmetry: if the proposal charges promptly for additions but says nothing about credits when a feature is dropped, that imbalance is telling you something.

IP ownership: the clause where buyers assume wrong

This is the clause buyers get wrong most often, because they assume they already know the answer. The assumption is "I paid for it, so I own it." In most jurisdictions that assumption is legally wrong. The default position in copyright law is that the rights in a created work belong to the author, the agency that made it, not to the client who commissioned and paid for it, unless the contract explicitly assigns those rights. This holds broadly under UK law, and under US law a commissioned website generally needs an express written assignment too.

The consequence is sharp. A proposal silent on intellectual property leaves you, by default, not owning the website you paid to have built. You may hold an implied licence to use it, but not ownership, not the unrestricted right to modify it, and not the clean right to hand it to a different agency later. So the proposal must state explicitly that on receipt of final payment all intellectual property rights in the deliverables are assigned to you. Then check the nuances. Third-party components cannot be assigned, because open-source code, stock images, premium plugins and fonts carry their own licences and the agency can only pass on what it created, so a proposal that separates "our work product" from "licensed third-party components" is being correct, not evasive. If the agency keeps ownership of its internal framework and grants you a licence, that is acceptable only if the licence is perpetual, irrevocable and royalty-free. And owning the live site is not the same as receiving the source files and code repository, so the proposal should commit to handing those over.

The five clauses that protect the buyer

Pull all of that together and five clauses, present and properly worded, tell a CFO the proposal protects the buyer rather than only the seller.

The first is the intellectual property assignment clause. It must state that all rights in the deliverables are assigned to you on final payment, carve out third-party components honestly, and commit to delivering the source files and repository. Without it, you do not own what you bought.

The second is the change-control clause. It must publish a rate and set out a written quote-and-approve-before-work process for anything outside scope. With it, scope creep stays priced and visible. Without it, every change is a negotiation you are positioned to lose.

The third is the milestone payment clause. It must tie cash to defined, inspectable deliverables, keep the deposit well under half, and ideally hold a small retention until the warranty window closes, so the money and the delivered value move together.

The fourth is the acceptance and sign-off clause. It must define the test for "done": what you review, how long you have to review it, and what counts as acceptance. This is what stops "launch" and "completion" from becoming the agency's word against yours.

The fifth is the warranty or defect-liability clause. It must state a window after launch, commonly thirty to ninety days, during which the agency fixes defects in delivered work at no charge, and define the line between a defect, which is free, and a change, which is billable. Two further protections are worth a glance: a termination clause stating what is owed if either side walks away, and clear wording on who holds the hosting and domain credentials so you are never locked out of your own site.

Asking these questions is the professional thing to do

If you are not a lawyer or a CFO, interrogating a proposal can feel awkward, especially when the agency is friendly and the mockups look good. It should not. Asking these questions is normal and professional, and a good agency welcomes it, because a tight proposal protects both sides; the disputes it prevents are painful for the agency too. Reading a proposal carefully is not you against them. It is both of you agreeing, in writing, what you have actually agreed.

That is the standard we hold ourselves to at WitsCode. We write proposals a CFO can read without flinching: itemised scope with templates and integrations named, an explicit exclusions section so there are no surprise invoices, payment tied to milestones you can inspect, a published change-order rate, and a clear assignment of intellectual property to you on final payment. If you are weighing up a website project and want to see what a proposal looks like when it protects the buyer as much as the agency, ask us for one before you spend a thing.

Get weekly field notes.

Practical writing on shipping products, straight to your inbox. No spam.

Need help with this?

WordPress Development

We design and build web apps, MVPs, and SaaS products. Talk to us about what you are working on.

Talk to us

Want to discuss choosing a web agency / pricing / contracts for your business?

Start a project and we'll talk through where you are, what's working, and the highest-leverage moves for the next 90 days.