The price is the part of a proposal everyone reads first. It is also the least useful part. Two quotes can carry the same number and describe completely different projects, and you only find out which is which in week six.

We write a lot of proposals, and clients regularly bring us other studios' proposals to look over. I have reviewed somewhere between 50 and 60 of them, most shown to me by clients comparing their options. This is how we read one, and what we think you should have in hand before you sign.

One proposal stays with me. A studio had offered a client everything, from branding to SEO to the website to a SaaS product, at an extremely low price. We told the client they were free to go with that studio, because we could not compete with it. Prices like that do not build trust. They make a careful buyer wonder what has been left out.

Read the scope as a list of nouns

"A modern, responsive website" is a mood, not a scope. A scope you can hold someone to names things: the pages or screens, the templates, the integrations, the forms and where they send data. If you cannot count the deliverables, you cannot tell when the work is done, and neither can the studio.

The same test applies to apps and SaaS products, where the nouns are flows. "User onboarding" is vague. "Sign-up, email verification, first project setup and the empty dashboard" is something you can tick off.

Read the exclusions before the inclusions

The most revealing section is the one that says what is not included. Good proposals have one. Weak ones skip it, and the gaps arrive later as change requests. These are the usual silent exclusions:

Writing the copy, or editing the copy you supply
Photography, illustration and stock licences
Moving content over from an old site
Third-party costs: fonts, plugins, hosting, email services, app store accounts
Accessibility testing beyond the basics
Analytics setup, and which events get tracked

None of these is wrong to exclude. Not knowing is the problem.

The assumptions are where projects slip

Every timeline rests on assumptions about you: how fast feedback comes back, how many people approve, whether the content exists when design starts. A proposal that lists them is telling you where it is fragile. One that doesn't is hoping you won't ask.

Ask who gives final approval and how many people feedback will come from. Decisions are the commonest reason a schedule moves. We are working on a booking platform right now where one technical decision is still open. We sent the proposal about two months ago, and we are still waiting for an answer. We expect the project to come to us, but until that one question is settled, the scope cannot be closed, and nothing after it can be planned properly. A single open decision can hold up everything behind it.

Revision rounds, and what counts as one

"Unlimited revisions" sounds generous and usually means nobody has defined the end. A clear proposal says how many rounds are included and what a round is.

At Bulb, revisions are written into the proposal. A design project typically includes three to five rounds of revisions. Beyond that, the extra work is charged. A design change that falls outside the agreed revision rounds is also scoped and charged separately, because it goes beyond what was agreed at the start. A revision refines what was agreed, such as spacing, wording or colour weight. A change of direction, like a different layout concept or a new feature, is a change request.

We work hard to keep it from coming to that. Understanding what a client wants within the agreed rounds is a design skill, and it is part of what you are paying a studio for. If a proposal does not draw this line, you will be negotiating it later, at the worst moment.

Timelines need dependencies

A timeline with dates and no dependencies is a wish. Look for what has to happen before each stage can start: content delivered, a sign-off given, access to hosting or analytics. The useful ones read like "design starts once the sitemap is approved and brand files are in."

On our own service pages we say a corporate site takes four to six weeks and a landing page one to two, and those figures still hold. They only hold if content and decisions arrive on time, which is exactly why they come with conditions.

Ownership and handover

Who owns the design files, the code and the domain when the project ends should be in the proposal in plain words, not discovered in a dispute. We cover it properly in who owns the design files, code and domain. For now, make sure it is written down somewhere you can find it.

Payments should follow deliverables

Payments tied to a date rather than to something you can see mean you pay whether or not the work moved. Milestones that map to an approved design, a working staging site and a launch keep both sides honest.

Who actually does the work

Ask who will design and build, and whether any of it is subcontracted. Neither answer is a problem on its own. Not being told is.

Ours is a small, lean team. Our designers and developers are in-house and responsible for every part of a project, and I oversee everything from design through implementation to code, with a quality check before anything goes to a client. We do not subcontract a project without the client knowing. If something is beyond us, we suggest one of our partner organisations and work alongside them.

Phrases worth a follow-up question

"Unlimited revisions": what counts as a revision, and when does the project end?
"SEO-friendly": what is included: titles, structure, speed targets, redirects from the old site?
"Fully responsive": which devices and screen sizes do you test on, and who signs off?
"Custom design": is it designed from a blank page or adapted from a template? Both can be fine; you should know.
"Fast turnaround": fast compared with what, and what do you need from me to make it true?
"Ongoing support": how many hours or days, for what kind of issue, and with what response time?

Comparing three proposals

Put them in a grid. Rows: what is delivered, what is excluded, assumptions about you, revision rules, timeline and its dependencies, ownership, payment structure, support after launch. Leave a cell blank when a proposal is silent. The blanks are the comparison. The proposal with the most blanks is not necessarily from the worst studio, but it is the one where you will do the most guessing.

Five questions to send before you sign

What would make you change the timeline or the cost, and how will you tell me?
Who is my point of contact, and how often will I see work in progress?
What do you need from me, and by when?
What happens if I don't like the first design direction?
What do I receive on launch day: files, access, documentation?

If you are still working out what to ask for before you brief anyone, a free website audit shows where your current site loses people and gives you something concrete to put in a brief. You can also see how we approach web design and digital platforms.

Reading a design agency proposal: what most of them leave out