How to Scope a SaaS MVP With an Agency (Without Getting Burned)

Most failed agency projects do not fail in the build. They fail in the scope. The scope was vague, both sides filled in the blanks with different assumptions, and the fight started in week six when the gap surfaced.

You can avoid almost all of this with two or three hours of real scoping work upfront. This post is how to do that work. It is written for founders hiring an agency for the first time, but the same logic applies if you are on your fourth build.

Why scope creep happens (it is not greed)

Scope creep is almost never the agency trying to over-charge. It is usually one of three things:

1. The founder genuinely did not know what they wanted in week one. They see v1 in week five, realise what they actually needed, and ask for it. Fair — but it is a change, and it has to be priced as one.
2. The scope document was written in marketing language, not engineering language. "User management" means seven different things. If the scope does not say which seven, you will not get the one you meant.
3. Nobody wrote down the edge cases. Happy-path features are easy to scope. The real work is in the "what happens when" — refunds, cancellations, role transitions, partial failures, offline behaviour. If you did not talk about those, you did not scope them.

All three are preventable, but only if you insist on a real scoping process before you sign.

What a good working session looks like

A scoping session is not a sales call. It is a 90-120 minute working meeting with one goal: produce a written scope document that both sides can point at in week ten and agree means the same thing.

Here is what ours looks like, as one example — adapt for whoever you hire.

Before the call, you send:

• A one-page business model description (who pays, what for, how often)
• Three to five example user stories in plain English ("a student enrols in a cohort, pays, gets access to week 1 content only, then week 2 unlocks on Monday…")
• Any existing screens, no-code builds, or competitor products that look like what you want

In the call, we walk through:

• The entities in your business (students, instructors, cohorts, payments, certificates) and how they relate
• Every user role and what each can see and do
• The critical flows end-to-end, including failure cases
• Integrations with third parties and whether you have access yet
• What is explicitly out of scope (this is the most important list)

By end of the call, we should have:

• A whiteboard photo of the data model
• A bulleted list of in-scope features, each one small enough to estimate
• A bulleted list of out-of-scope features, named so they cannot "sneak in"
• A rough week-by-week schedule with demo milestones

After the call, the agency sends a written scope document within 48 hours. If they do not, they are not going to be disciplined during the build either.

IJRN: a real scope process

When we started the IJRN academic journal platform, the founder came in with "a submission and peer-review system." That phrase could mean a two-week build or a six-month build. The scoping session pinned it down:

• Roles: author, reviewer, editor, admin. Four roles, each with a tightly-defined permission matrix.
• Manuscript state machine: submitted → under review → revisions requested → accepted or rejected → published. Five states, four transitions, each with different email triggers.
• What was explicitly out of scope for v1: DOI registration automation, Crossref integration, plagiarism checker, reviewer rating system. Each was listed by name with "phase 2 candidate" next to it. When the founder asked for one of them in week eight, nobody had to argue — the doc said phase 2.

The scoping call took two hours. It saved us, conservatively, three weeks of re-work. Our breakdown of SaaS MVP timelines has more on how IJRN ran to schedule because of that discipline.

How to write a scope document that actually holds

A real scope document has four sections. If any are missing, push back.

1. Feature list, with acceptance criteria. Not "user management" — "admin can invite a new user by email; invited user receives an email with a signup link valid for 7 days; on signup, user is assigned one of three roles set by admin; admin can deactivate but not delete a user; deactivated users cannot log in." That is one feature.

2. Out-of-scope list, named. Every feature that came up in conversation and is not being built. Written down by name. Saves the week-eight argument.

3. Tech stack and ownership. What stack is being used, what cloud, what database, what the repo structure looks like. Who owns the code, the domain, the database, and the deployment accounts. Answer is always "you do."

4. Timeline with demo milestones. Weekly demo cadence with a specific day and time. Listed milestones at the end of each two-week block. If there is no fixed demo day, the build will slip and you will only notice in week ten.

If you want us to review a scope document an agency sent you — your own or ours or anyone else's — we will mark it up with what is missing. It is a 45-minute read and it has saved founders several lakh INR of regret.

Fixed-price vs hourly: which to pick

Fixed-price is right when:

• The scope is genuinely well-defined and unlikely to change
• You want predictable cashflow
• You are willing to pay a 15-20% risk premium for that predictability
• You will discipline yourself to submit change requests for anything new

Hourly (or time-and-materials with a cap) is right when:

• The product will evolve based on real user feedback in the first month
• You trust the team and want flexibility
• You are willing to do more project management in exchange for agility

Most MVPs we do are fixed-price with a clearly-named "phase 2 pool" of hours at a pre-agreed rate. That covers the things both sides know will come up without pretending they won't.

The one rule that beats every other rule

Write. Everything. Down.

Every decision made on a call. Every scope change. Every "let's do it this way instead" moment. Put it in a shared doc with a date. When week twelve rolls around and someone says "I thought we agreed to…" the doc answers without anyone having to remember.

Agencies that resist this are the ones who benefit from the ambiguity. Run.

What to do next

If you have a SaaS idea and you are about to start talking to agencies, the best thing you can do this week is write your own one-page business description and three user stories. That single document changes what you can demand from the agencies you talk to — including us.

When you have that, book a working session with us or another team you are evaluating, and insist on the full scoping process above before you sign anything. If the agency balks, you have your answer. If they run it well, you have your partner.

You can also see how we have scoped past projects on our portfolio page — each of those builds came out of a scoping session that looked roughly like what we described here.