Reading a Web-Design Proposal Like an Operator

Two proposals land on your desk. Same headline price. One is three pages of specifics; the other is one page of adjectives. If you read them the way most people do — skip to the number, glance at the vibe, sign — you'll treat them as interchangeable. They are not. Behind the identical price sit two completely different products, and the only way to see the difference is to read like an operator: line by line, asking what each line actually commits someone to do.

Here's how I read a proposal, which is also how I write mine, because the guardrails I hold myself to are the same literacy I want you to have as a buyer.

Rule one: every line should be a noun you can verify

Scan the deliverables. Are they things — "eight service pages," "a contact form delivering to X," "a sitemap," "schema for your locations" — or are they moods? "Ongoing optimization." "Strategic guidance." "Performance enhancements." A noun can be checked off; a mood can be billed forever without producing anything. When a proposal's deliverables are mostly moods, you're not buying work, you're buying vocabulary. The single best test of a proposal is how many lines survive translation into "a specific thing that will exist that doesn't exist today."

Rule two: the monthly section is where the truth hides

The build is a one-time thing; you'll see whether it got made. The retainer is where proposals get away with murder, because "ongoing" is invisible by design. So read the monthly section hardest. What ships each month, in nouns? Content, page rewrites, rankings reviewed, indexing verified? Or "management," "maintenance," and "optimization" — the three words that mean "you will be billed and you won't be able to tell whether anything was done"? A retainer you can't audit is a subscription, and your SEO retainer is probably plugin updates if the monthly line won't resolve into shipped work.

Rule three: find the ownership clause

Somewhere in the document is the answer to who ends up owning the domain, the code, and the accounts. It's often not in the deliverables — it's in the terms, in smaller type. Read it. A proposal that quietly registers your domain to the agency, or keeps the code somewhere you can't reach, is offering you a beautiful site and a leash in the same breath. The correct answer is that you own everything, and it should be stated, not implied.

Rule four: compare the two proposals on specificity, not price

Now put them side by side. If they're the same price and one has three times the verifiable nouns, they're not the same price — one is a far better deal, and the "expensive-feeling" vague one is the actual rip-off. Buyers routinely pick the cheaper-feeling proposal, which is the vaguer one, because vagueness reads as flexibility. It isn't. It's the absence of commitment, priced identically to commitment. The seven questions I'd ask any designer are really just this literacy applied out loud in a meeting.

Why I write mine this way

I itemize because the alternative is asking you to trust adjectives, and I'd rather earn a signature than extract one. My proposals resolve into nouns — what gets built, what ships monthly, who owns what — precisely so you can do to mine exactly what I've just told you to do to everyone's. If a line in my proposal doesn't survive the "specific thing that will exist" test, it shouldn't be in there, and you should call it out. The guardrails aren't a marketing pose; they're the same discipline pointed inward.

Inquire and I'll show you a real one — itemized, ownership stated, monthly work in nouns — so you have a specific thing to compare against. Inquire about a project →