Buying, Building, and Reviewing Tech Work — Lesson 1
Scope, Proposals, and Clarity
Learning Objectives
- 1Evaluate vendor proposals for completeness and clarity.
- 2Identify hidden costs, vague deliverables, and missing exclusions.
- 3Write project briefs that produce accurate proposals.
What makes a good proposal
A good proposal clearly defines what will be delivered, by when, for how much, and under what conditions. It lists specific deliverables — not vague descriptions like "a modern website" but concrete items like "a 10-page responsive website with contact form, blog, and CMS access." It defines what is included and, equally importantly, what is excluded.
Vague proposals protect the vendor, not the client. "We will build your website" leaves room for wildly different interpretations. "We will build a WordPress website with the following pages, features, and integrations, delivered by this date, with these revision rounds included" sets mutual expectations.
Before evaluating any proposal, ensure your own project brief was specific enough. A vague brief produces vague proposals. If you asked three vendors for "a new website" and received three dramatically different proposals, the problem may be your brief, not the vendors.
Proposal red flags
Vague deliverables without specifics. No explicit exclusions or out-of-scope items. 100% payment upfront. No defined revision or change process. No timeline with milestones. No mention of post-launch support. These are signals that the project is under-specified.
Reading between the lines
Proposals often have implicit assumptions that create conflict later. "Content provided by client" assumes you have all content ready. "Design based on standard templates" means limited customization. "Testing included" might mean only the developer checks their own work.
Ask about assumptions explicitly: What are you assuming about content readiness? What is included in "testing"? How many revision rounds are included? What happens if the timeline slips? What does "support" mean after launch? Each assumption is a potential disagreement if not addressed before signing.
Compare proposals on scope, not just price. The cheapest proposal may exclude items the more expensive proposals include. Build a comparison matrix: list every deliverable mentioned in any proposal and check which proposals include each item. This reveals what you are actually comparing.
Writing effective project briefs
A project brief should describe: the business problem or goal, the target audience, the specific deliverables needed, the technical requirements (integrations, platforms, constraints), content and asset availability, timeline expectations, budget range, and how success will be measured.
Including a budget range is controversial but practical. It helps vendors propose solutions appropriate to your investment level instead of guessing. A vendor who knows the budget is $20,000 will propose differently than one guessing whether the budget is $5,000 or $100,000.
Reference examples of what you like and do not like. "We want a site similar to [example] but with less emphasis on video and more on lead capture" gives vendors concrete direction that descriptions alone cannot convey.
Case Study
The $15,000 gap
Situation
A company received two proposals for the same website project. Vendor A quoted $18,000. Vendor B quoted $33,000. The company chose Vendor A based on price. After three months and multiple change orders, the total cost with Vendor A was $38,000 — more than Vendor B original quote. Vendor B proposal had included items that Vendor A treated as extras.
Analysis
The proposals were not comparable because they had different scopes. Vendor A excluded mobile optimization, CMS training, SEO setup, and post-launch support — all of which Vendor B included. The cheaper quote was only cheaper because it covered less work.
Takeaway
Compare proposals on total scope, not just initial price. The cheapest proposal often excludes items that become expensive add-ons later.
Reflection Questions
- 1. Think about the last vendor proposal you evaluated. Were all deliverables specific? Were exclusions listed?
- 2. If you were writing a project brief today, what information would you include that you did not include last time?
Key Takeaways
- ✓Good proposals define specific deliverables, explicit exclusions, milestones, and change processes.
- ✓Vague proposals protect vendors — push for specifics before signing.
- ✓Compare proposals on total scope, not just initial price.
- ✓Your project brief quality directly determines proposal quality.