Business

How to Scope an MVP Before You Hire a Software Agency (With a Free Brief Template)

Vague briefs get vague quotes. An hour spent scoping your MVP will save weeks later and make every agency's estimate easier to compare.

By Prolificrew Engineering · · 3 min read

In this article
  1. Start with the problem, not the features
  2. Define the core loop
  3. Sort features into three groups
  4. Decide how you will know it worked
  5. Name your constraints
  6. Things worth deciding before you hire
  7. A brief template you can copy
  8. How to compare the quotes you receive
  9. Want a second opinion on your scope?

Founders often contact a software agency with an idea and ask 'how much for this?'. The honest answer is 'it depends', and the quotes that come back can differ enormously because each agency is pricing a different guess. You can fix that before you speak to anyone. A good scope turns an idea into a short document that any engineer can read and estimate. This article walks through how to write one, and ends with a template you can copy. For background on what drives the price once you have a scope, see our guide to custom software costs.

Start with the problem, not the features

Write one or two sentences describing who has the problem, what they do today and why that is painful. 'Independent physiotherapists lose time chasing missed appointments by text' is a problem. 'An app with a calendar and notifications' is a solution. Agencies can only suggest the right solution if they understand the problem, and you will notice features that do not serve it.

Define the core loop

Every product has one repeated action that delivers value: a customer books a slot, a manager approves an expense, a creator exports a finished clip. Describe that loop as a short sequence of steps from the user's point of view. The MVP is the smallest product that lets someone complete that loop for real. Everything else is a candidate for later.

Sort features into three groups

GroupMeaningExample for a booking app
Must haveThe core loop does not work without itCreate a booking, confirm it, see it in a list
Should haveMakes it pleasant, but users can start without itReminder emails, rescheduling
Not nowReal ideas, but they would delay learningTeam accounts, analytics dashboard, mobile app

Be strict. A useful test for each 'must have' is: if we launched without this, could we still learn whether people want the product? If yes, it is not a must.

Decide how you will know it worked

Pick one or two measurements that prove the idea, chosen before building. Examples: ten pilot customers completing the core loop in the first month, a share of trial users coming back in the second week, or a specific manual process replaced. Without this the project has no finish line, and every request sounds equally important.

Name your constraints

  • Budget range and deadline: a range is fine. Agencies can propose what fits it, which is better than guessing.
  • Platforms: web only, or also iOS, Android or desktop? Starting with one is usually wiser. Our mobile guide can help if you are choosing.
  • Integrations: payments, email, calendars, accounting, existing systems. These often take longer than the screens.
  • Data and compliance: do you handle personal, financial or health data? Say so early, because it changes the design and the cost.
  • Existing assets: designs, brand, code, user research, a prototype.

Things worth deciding before you hire

  • Who owns the code? You should, with the repository in your account from the first day.
  • Who makes product decisions? One named person on your side who can answer questions within a day.
  • How will you work? Short iterations with a working demo every week or two are easier to steer than a big reveal.
  • What happens after launch? Hosting, fixes and the next round of features should be discussed upfront.

A brief template you can copy

PROJECT BRIEF

1. Problem
   Who has it, what they do today, why it hurts.

2. Target users
   Who will use v1? How many in the first three months?

3. Core loop
   Step 1 -> Step 2 -> Step 3 (the one thing the product must do).

4. Features
   Must have:
   Should have:
   Not now:

5. Success measures
   What result in what time proves the idea?

6. Platforms and integrations
   Web / iOS / Android / desktop. Payments, email, other systems.

7. Data and compliance
   Personal or sensitive data? Regions? Regulations?

8. Budget range and target launch date

9. Existing assets
   Designs, code, research, competitors you admire.

10. Decision maker and availability

How to compare the quotes you receive

Compare what is included, not only the total. Check what they assumed, what is excluded, how many design and revision rounds are included, who tests, what the handover contains and how changes are priced. A very low quote usually has assumptions hiding in it. A quote that asks good questions about your core loop is usually a better sign than one that says yes to everything.

Want a second opinion on your scope?

We build MVPs for startups and teams, and we are happy to look at a draft brief and tell you where we see risk or features that can wait. Send it over and we will reply with honest feedback.

Keep reading