How to Scope a Software Project and Write a Brief Agencies Can Quote

The quality of the quotes you receive from development agencies is directly proportional to the quality of the brief you send them. A brief that says "I want to build an app like Airbnb" produces a quote that is either absurdly low (the agency priced a simple booking screen) or absurdly high (the agency priced the entire Airbnb platform). Neither number is useful.

You do not need a technical specification to get a useful quote. You need a structured brief that communicates what problem the product solves, who uses it, what the core user journey looks like, and what constraints (budget, timeline, compliance) shape the project. This guide walks through how to produce that brief, what to include, and what to leave out.

Why Scoping Before the Agency Conversation Matters

Three reasons the upfront scoping work pays off:

Better quotes. Agencies estimate based on what they understand. The more clearly you communicate the product, the tighter the estimate. A brief that describes the core user journey with enough specificity that the agency can count the screens, identify the integrations, and assess the complexity produces an estimate within 15 to 20 percent of the actual cost. A brief that describes a concept produces an estimate with 50+ percent variance.

Faster timelines. The discovery phase that agencies charge for (and that is covered in the discovery phase guide in this series) goes faster when the client arrives with a structured brief. A two week discovery becomes a one week discovery when the client has already done the product thinking. The agency’s discovery effort focuses on technical architecture and estimation rather than on extracting the product vision from the founder’s head.

Better agency selection. When all agencies receive the same detailed brief, you can compare their proposals on equal footing. Without a consistent brief, each agency interprets the project differently, and the proposal comparison becomes a scope comparison rather than a capability comparison.

The Scoping Framework: Seven Questions

You do not need a specification document. You need answers to seven questions. The answers become the brief.

Question 1: What problem does this product solve, and for whom?

Write two sentences. The first sentence describes the problem. The second describes who has it.

"Small restaurant owners spend 4 to 6 hours per week managing inventory manually across their POS system, their suppliers, and their accounting software. They need a tool that syncs these systems automatically and alerts them when stock is running low."

Not: "We are building a revolutionary inventory management platform that leverages AI to transform the restaurant supply chain." The first version tells an agency what to build. The second tells them nothing.

Question 2: What is the core user journey?

Describe the sequence of actions a user takes from first opening the product to completing the primary task. This is the critical path: the minimum set of steps that delivers the product’s core value.

For the restaurant inventory example: "The owner connects their POS system (Toast or Square), connects their primary supplier’s ordering system, and connects QuickBooks. The app pulls current inventory levels from the POS, compares them against par levels the owner sets, and generates a suggested order for the supplier. The owner reviews the order, adjusts quantities, and submits it. The order goes to the supplier and the purchase is recorded in QuickBooks."

This description gives the agency enough to estimate: 3 integrations (POS, supplier, accounting), an inventory dashboard with par levels, an order generation and review workflow, and a submission flow with accounting sync. They can count the screens, identify the integration complexity, and assess the data model.

Question 3: Who are the user types?

List every type of person who will use the product, with a one line description of what they do.

"Owner: connects systems, sets par levels, reviews and approves orders, views inventory reports. Manager: same as owner but cannot connect systems or change integrations. Supplier: receives orders, confirms availability, provides delivery estimates."

Each user type adds development scope: a separate login experience, a separate set of permissions, potentially a separate interface. The number of user types is one of the strongest predictors of total development cost.

Question 4: What are the 3 to 5 must have features for version 1?

Force yourself to identify the features that must be in the first release. Not the features you want. Not the features that would be nice. The features without which the product cannot deliver its core value.

For the inventory example:

POS integration (Toast and/or Square) for real time inventory data
Par level management with low stock alerts
Automated order suggestion based on par levels and consumption rate
Order submission to the supplier (email or supplier portal API)
QuickBooks sync for purchase recording

Everything else (advanced analytics, multi location dashboards, predictive ordering, supplier comparison, mobile app) is version 2. Writing the version 2 list is useful because it helps agencies understand the product’s trajectory, but it should be clearly labeled as future scope.

Question 5: What are the constraints?

Constraints narrow the solution space and help agencies estimate more accurately:

Budget: "Our budget for version 1 is $50,000 to $80,000." Sharing a range, not a fixed number, is covered in the quote comparison guide.

Timeline: "We need to launch by Q3 2026 because our pilot partner’s contract starts in September." A hard deadline changes the agency’s staffing and phasing decisions.

Platform: "The primary interface is a web dashboard. A mobile companion app is version 2." Platform choice affects framework selection and development cost.

Compliance: "The product must comply with PCI DSS because we handle supplier payment data." Compliance requirements add cost and affect architecture. Naming them upfront prevents mid project surprises.

Integrations: "Must integrate with Toast POS and QuickBooks Online. Square POS and Xero are version 2." Each integration is a cost line item. Being specific about which integrations are required prevents agencies from padding the estimate with integrations you do not need yet.

Question 6: What do users currently do instead?

The current alternative reveals the product’s competitive positioning and the user’s willingness to switch. "Owners currently use spreadsheets and manual counting" tells the agency the product replaces a manual process (lower switching cost, higher tolerance for imperfection). "Owners currently use a competitor product called InventoryPro but find it too expensive for single location restaurants" tells the agency the product competes on price and simplicity (different positioning, different feature emphasis).

Question 7: What does success look like in 6 months?

This question forces the founder to define the measurable outcome the product must produce. "20 restaurant owners using the product daily, with 80 percent of their weekly orders generated through the app" is a specific success metric. "We want to be the leading inventory management tool for restaurants" is not.

The success metric informs the scope: if success requires 20 users, the product does not need to scale to 10,000. If success requires daily use, the UX must be frictionless enough for daily interaction. If success requires 80 percent order adoption, the order workflow must be significantly faster than the manual alternative.

Structuring the Brief

Combine the seven answers into a single document. The structure:

Section 1: Problem and audience (2 to 3 paragraphs). The problem, who has it, what they currently do about it, and why the current solution is inadequate.

Section 2: Core user journey (1 page or less). The step by step flow from first use to core value delivery. Include enough detail that someone unfamiliar with the domain can follow the sequence.

Section 3: User types and permissions (a short list). Who uses the product and what each type can do.

Section 4: Version 1 features (a numbered list of 3 to 5 items). Each feature described in one to two sentences with enough specificity to estimate.

Section 5: Version 2 features (a separate numbered list). Clearly labeled as future scope. Helps the agency understand the product direction without inflating the version 1 estimate.

Section 6: Constraints. Budget range, timeline, platform, compliance, and required integrations.

Section 7: Success metric. What the product must achieve in 6 months to justify the investment.

The entire document should be 2 to 4 pages. Longer is not better. If the brief is 20 pages, you have either specified too much (leaving no room for the agency’s expertise to add value) or included too much context (making the agency work to find the relevant information).

‍

Seven translucent glass question mark tiles arranged in a row with red accents

‍

What to Leave Out of the Brief

Technology recommendations. Do not specify the framework, the database, or the cloud provider unless you have a technical reason (an existing codebase, a specific compliance requirement, or an in house team that uses a specific stack). Let the agency recommend the technology based on the project’s requirements. Their recommendation reveals their expertise and their reasoning.

Detailed screen designs. If you have wireframes or a Figma prototype, include them as reference. If you do not, do not try to describe screen layouts in text. "The dashboard shows the current inventory level for each item with a color coded indicator for low stock" is useful. "The dashboard has a left sidebar with navigation icons, a top bar with the user’s name and a notification bell, and a main content area with a table of inventory items in rows with columns for item name, current quantity, par level, and status, with a green circle for in stock and a red circle for low" is too detailed and constrains the designer unnecessarily.

Implementation details. Do not specify how features should be built. "The system checks inventory every 15 minutes by polling the POS API" is an implementation detail that may or may not be the right approach. "The system keeps inventory data current throughout the business day" is a requirement that the agency can solve using the approach that best fits the architecture.

Marketing language. The brief is a product specification, not a pitch deck. "Revolutionary AI powered supply chain optimization" does not help the agency estimate the work. "Automated order suggestions based on consumption rate and par levels" does.

Common Scoping Mistakes

Describing the solution instead of the problem. "We need an app with a dashboard, a notification system, and a reporting module" describes a solution. "Restaurant owners do not know when they are about to run out of inventory until they physically count what is on the shelves" describes the problem. The problem gives the agency the context to evaluate whether the solution is the right one. The solution alone does not.

Listing every feature imaginable. A brief with 40 features produces an estimate for 40 features. If the budget only supports 10 features, the estimate is useless because the agency has to guess which 10 you actually want. Prioritize before you send the brief, not after you receive the estimate.

Forgetting the constraints. A brief without a budget range produces an estimate that may be 3x what the founder can afford. A brief without a timeline produces an estimate that may plan for a 12 month build when the founder needs to launch in 4 months. Constraints are not limitations. They are information that helps the agency propose a realistic plan.

Specifying integrations without researching them. "Integrate with all major POS systems" sounds simple. There are dozens of POS systems, each with a different API, a different partnership model, and a different integration timeline. Specifying the 2 to 3 POS systems that the launch market actually uses, based on research with potential customers, produces a tighter and more realistic estimate.

Writing the brief alone. If you have potential customers, pilot partners, or domain advisors, share the brief with them before sending it to agencies. Their feedback catches assumptions about the user journey, the feature priorities, and the constraints that the founder may have wrong. A brief validated by 3 to 5 potential users is worth more than a brief validated by the founder’s intuition alone.

Using the Brief to Evaluate Agencies

The brief is an evaluation tool as well as a communication tool. When you send the same brief to 3 to 5 agencies, their responses reveal:

Which agencies read the brief carefully. An agency that responds with clarifying questions specific to your brief (not generic questions they ask every client) has read and thought about the project. An agency that responds with a template proposal that could apply to any project has not.

Which agencies push back on scope. A good agency will suggest that some of your version 1 features belong in version 2, will identify features you forgot, and will challenge assumptions about integrations or compliance requirements. An agency that agrees with everything in the brief without comment is either inexperienced or not invested enough to push back.

Which agencies understand your domain. An agency with restaurant technology experience will respond to the inventory example with domain specific insights: "Toast’s API has rate limits that affect real time inventory polling, so we recommend a webhook based approach instead." An agency without that experience will respond with generic architecture proposals.

Which agencies communicate clearly. The quality of the agency’s proposal reflects the quality of their communication throughout the project. A clear, specific, well organized proposal predicts clear, specific, well organized project communication. A vague, generic, disorganized proposal predicts the same for the project.

Bolder Apps runs a scoping process that takes the brief, identifies gaps and risks, and returns a fixed scope proposal within 1 to 2 business days. The speed reflects pattern recognition from similar builds, and the proposal quality tracks directly to the brief’s clarity. Sending the same structured brief to multiple agencies and comparing their responses is the most controlled way to evaluate communication quality and scope interpretation across competing proposals.

‍

A glass funnel turning loose idea fragments into a neat glass brief document

‍

From Brief to Discovery to Build

The brief is the first artifact in a three step sequence:

Step 1: Brief (produced by the founder). Communicates the product vision, the constraints, and the priorities. Used to solicit proposals from agencies.

Step 2: Discovery (produced by the agency). Takes the brief and translates it into a buildable specification: wireframes, technical architecture, detailed scope document, and estimate. The discovery phase fills in the details the brief intentionally leaves out: screen designs, data models, integration architecture, and technical approach.

Step 3: Build (executed by the agency against the discovery outputs). The scope document from discovery becomes the contract basis for the development engagement. The wireframes become the specification for the designer. The architecture document becomes the blueprint for the engineering team.

Each step adds specificity. The brief describes what and why. Discovery adds how. The build executes it. Skipping step 1 (going directly to discovery without a brief) costs time because the agency spends discovery extracting information the founder could have provided upfront. Skipping step 2 (going directly to build without discovery) costs money because the agency estimates from an incomplete understanding and the inevitable scope changes during development exceed whatever the discovery phase would have cost.

The Brief Template

For founders who want a starting template:

PROJECT BRIEF: [Product Name]

1. PROBLEM AND AUDIENCE

[2–3 paragraphs: What problem, who has it, what they do today, why it is inadequate]

2. CORE USER JOURNEY

[Step by step: what the user does from first use to core value delivery]

3. USER TYPES

[Type 1]: [what they do]
[Type 2]: [what they do]
[Type 3 if applicable]: [what they do]

4. VERSION 1 FEATURES (must have)

[Feature]: [1–2 sentence description]
[Feature]: [1–2 sentence description]
[Feature]: [1–2 sentence description]
[Feature]: [1–2 sentence description]
[Feature]: [1–2 sentence description]

5. VERSION 2 FEATURES (future scope)

[Feature]
[Feature]
[Feature]

6. CONSTRAINTS

Budget: [range]
Timeline: [target date and reason if applicable]
Platform: [web, mobile, both]
Compliance: [if applicable]
Required integrations: [specific services]

7. SUCCESS METRIC

[What the product must achieve in 6 months]

Fill this in before your first agency conversation. It takes 2 to 4 hours. Those hours are the highest leverage hours you will spend on the entire project because they determine the quality of every estimate, every proposal, and every development decision that follows.

Common Brief Mistakes by Industry

Different industries produce different brief mistakes based on the domain knowledge the founder brings:

Healthcare founders over specify the clinical workflow and under specify the technology requirements. The brief describes the patient journey in clinical terms but does not address: which data is ePHI (and therefore subject to HIPAA), which integrations are needed (EHR, scheduling, billing), and what the compliance requirements mean for the architecture. The fix: add a "compliance and regulatory" section to the brief that lists every regulation that applies and every third party system the product must connect to.

Fintech founders over specify the financial product and under specify the compliance infrastructure. The brief describes the lending product, the payment flow, or the budgeting features but does not address: PCI DSS scope, KYC/AML integration requirements, state licensing implications, and data privacy obligations. The fix: add a "regulatory landscape" section that maps the compliance requirements the product must meet before launch, not after.

Marketplace founders under specify the trust and safety requirements. The brief describes the buyer and seller flows but does not address: how disputes are resolved, how fraudulent listings are detected and removed, how reviews are moderated, and how payment holdback works. These are not edge cases. They are core platform operations that affect development cost and architecture. The fix: add a "trust and safety" section that describes how the platform handles the transactions that go wrong, not just the ones that go right.

Consumer app founders under specify the growth and retention mechanics. The brief describes the features but does not address: the notification strategy, the onboarding flow’s conversion targets, the retention mechanics that bring users back, or the analytics infrastructure needed to measure engagement. The fix: add a "growth and retention" section that specifies the engagement features and the metrics that determine whether the product is working.

In each case, the brief mistake comes from the founder’s domain expertise creating a blind spot: they deeply understand their industry but do not know which technical and operational requirements that industry imposes on the software. A development partner who asks the questions the founder did not think to answer is more valuable than one who builds exactly what the brief says.