How to Read a Software Agency's Scope Document Like a Buyer

A software agency proposal is easy to skim and hard to read. The interesting stuff is almost never on page one. This post is the review you'd get from a founder who's signed a few and been burned by one — the clauses that matter, the numbers that don't say what they seem to, and the questions worth asking before the contract goes back.

Yes, we're an agency writing this. It's still good business for us: the projects that succeed are the ones where the buyer read the scope carefully. The rest end up somebody's cautionary tale.

What a good scope document actually looks like

A tight scope document has four parts:

• Objectives — what the software must do, in outcome terms.
• Deliverables — the specific artifacts you'll get.
• Assumptions and exclusions — what the estimate depends on, and what's out of scope.
• Timeline, payment, and change process — how the work runs.

If any one of those four is thin, that's where the pain will come from later. Weak assumptions become surprise change orders. Vague deliverables become "we thought that was included." Missing change processes become "everything is a change request."

What to check, section by section

Objectives

Read this for outcomes, not features. "Users can log in with Google, GitHub, and email" is a feature. "Reduce signup drop-off to under 20%" is an outcome. A good proposal will mix both — features to ship, outcomes to hit.

If the objectives are pure feature lists, ask the agency what business result the features are meant to produce. If they don't have an answer, they'll build features without thinking about the outcome — and you'll pay for polish on the wrong things.

Deliverables

These should be specific. "A working MVP" is not a deliverable. "A deployed web application with the following user flows: X, Y, Z, admin dashboard covering A, B, and integration with Stripe billing" is a deliverable.

Look for these specifically:

• Source code access and where it lives (your GitHub org, not theirs).
• Deployment access and account ownership.
• Documentation — even a lightweight README with setup and architecture notes.
• Handover call or session at the end.

Assumptions and exclusions

This is where the honest proposals separate from the sloppy ones. A serious agency will list assumptions like:

• "Client provides brand assets and copy by week 2."
• "Design system is provided; if not, add 3 weeks for design work."
• "Third-party APIs (Stripe, Twilio) are accessible within their standard limits."

If assumptions are missing, the estimate is a guess dressed as a quote. Add "what happens if any of these turn out different?" to the negotiation.

Timeline

Fixed dates or ranges? Ranges are honest. Fixed dates with no buffer are either optimistic or padded — you can't tell which.

Look for milestone-based breakdowns. A six-week project with a single "done" date is opaque. A six-week project with three milestones each with a demo is manageable.

Payment terms

Common shapes:

• Fixed price, milestone payments — best for clearly-scoped projects.
• Time and materials with a cap — best for exploratory work.
• Retainer — best for ongoing engagements.

Watch for large upfront payments (over 30%) with no delivery attached. Watch for final payments under 10% — that means the agency has almost no incentive to nail the last mile.

Change request handling

Every project has changes. The question is how they're handled. Look for:

• A defined process for scope changes (usually written change orders).
• Hourly rates or day rates for out-of-scope work.
• A "small changes" allowance — most agencies absorb small tweaks up to some threshold.

The worst version is silence. "Everything after signing is a change order at $X/hour" leads to bad-faith negotiation for the whole project.

IP and ownership

Non-negotiable clauses to insist on:

• All code produced for you is your property upon final payment.
• Agency retains no rights to the specific implementation.
• Reasonable exclusions for the agency's pre-existing libraries and internal tools.

Any agency uncomfortable with this is a red flag. Standard boilerplate for reputable shops.

Confidentiality and data handling

If your product handles user data, the contract must specify:

• Who has access to what data.
• Where dev/staging data lives.
• Retention and deletion policies at the end of the engagement.

Red flags to watch for

"We'll figure it out as we go"

Sometimes fine for very early work. Not fine for anything with a budget. Ambiguity favors the party writing the invoice, and that's not you.

Estimates without a range

"This will be $47,300" is unnaturally precise. A serious estimate has a range and lists what would push it up or down.

No named team

Who's actually going to work on your project? If the proposal doesn't name a lead and give you a chance to meet the engineers, you're signing to a brand, not a team.

Massive discount for "signing this week"

Pressure tactics on scope documents suggest the pipeline is thin. That's not a reason to walk away, but it is a reason to slow down.

Vague testing and QA plans

"Testing included" without specifics usually means "we'll ship and hope." Ask what testing looks like — unit tests, e2e tests, manual QA, staging environment for you to review.

Questions worth asking before signing

• Who is the technical lead, and can I have a 30-minute call with them?
• What's the last project you shipped that resembles this one?
• What's the biggest project you've had go over budget, and why?
• Which parts of this scope are you most confident about, and which are hardest to estimate?
• What would kill this project — what conditions would make you recommend we don't proceed?

The last one is the tell. An agency that can't answer it either hasn't thought about your project or isn't being honest.

Where scope docs go wrong on both sides

The founder side

Signing without reading the assumptions. Requesting "just this one thing" that's out of scope and then not agreeing to the change order. Delaying feedback on milestones, then blaming the agency for the delay. Every agency has stories.

The agency side

Underestimating on purpose to win. Padding change orders. Assigning the least experienced engineers after selling the senior ones. Also common stories.

A good scope document protects against both. Read it as if you'll need to enforce it, and negotiate as if you want the project to succeed — not just as if you want the lowest price.

Common misconceptions

"A cheaper quote means better value." Sometimes. Also often means missing scope that shows up as change orders later. Compare the assumptions section as carefully as the price.

"Fixed price is safer than time and materials." Fixed price is safer when the scope is well-defined. T&M with a cap is safer when the scope is exploratory. Wrong shape for the wrong project causes more losses than either shape does on its own.

"We can add things later." Yes, but the price is different. Bake the "later" list into the initial scope with clear estimates, or accept that it's a separate project.

Frequently Asked Questions

Should I hire a lawyer to review a software agency contract?
For anything over $50K, yes. Under that, a careful founder read plus one call with the agency's technical lead usually catches the major issues.

What percentage should I pay upfront?
10–30% is normal. Over 50% upfront is a red flag unless there's a very specific reason (custom hardware, pre-purchased licenses).

How long should the scope document be?
Ten to twenty pages for most SaaS projects. Under five pages is thin; over forty is often overengineered and hides the important stuff.

Can I ask an agency to revise their proposal?
Yes. Any agency worth working with will negotiate scope, milestones, and terms. Refusing to revise anything is a red flag.

Where to go next

If you're earlier in the process, our post on how to hire an AI development agency covers the vendor selection side. For the internal side, the AI development contract checklist is a useful complement.

Working with us

We're on the other side of these conversations most weeks. If you're comparing proposals right now and want a second opinion, get in touch — happy to review a scope document even if you end up going with someone else.