How to Brief a Software Agency: What to Send Before You Sign Anything

Most founders walk into an agency conversation with a Notion doc, a rough idea, and a budget they’re embarrassed to share. They get wildly different quotes back – sometimes a $40K gap between proposals – and blame the agencies. In our experience, the brief is almost always the problem. Vague input produces variable output, and every assumption a developer has to make in your absence gets priced as risk. The agency that comes in cheapest usually made the most optimistic assumptions. The one that came in expensive might just be more honest about what you’re actually asking for.

This isn’t a post about how to evaluate agencies. It’s about what to prepare before you even pick up the phone – the stuff that separates a founder who gets a grounded proposal from one who gets a number pulled from thin air.

Start With Outcomes, Not Features

The single biggest mistake we see in briefs is a feature list where a problem statement should be. “I need a dashboard, an onboarding flow, a payment system and an API” tells us almost nothing useful. What we actually need to know is: what changes in your business when this software exists?

That sounds abstract, but it’s practical. If your answer is “our ops team stops manually processing 300 orders a week,” that shapes everything – the data model, the integrations, the edge cases we have to plan for. If your answer is “customers can self-serve instead of emailing us,” the scope looks completely different again.

Write two or three sentences describing the before state (what’s broken or slow or missing) and the after state (what a working version makes possible). That’s your north star for the whole brief, and it forces every feature decision to justify itself.

The Functional Spec Doesn’t Need to Be Perfect – It Needs to Be Honest

You don’t need a full technical specification. You need a clear description of what the software does, from a user’s perspective, at the level of “a user can do X” statements. Not wireframes. Not database schemas. Just behaviour.

Walk through your main user types – founders often forget there’s more than one – and describe what each of them needs to do inside the product. For a B2B SaaS, that might be an admin, an end user, and a billing contact. For an internal ops tool, it might be a warehouse manager and a finance approver. Spell out the key flows for each.

Then – and this is the part most briefs skip – flag what you’re deliberately leaving out. Scope is as much about what you’re not building as what you are. If you know version one won’t have a reporting module, say so. It prevents the agency from quoting it and prevents you from arguing about it later.

Integrations Are Where Budgets Go to Die

List every third-party system your product needs to talk to. Not the ones you might add later – the ones it cannot launch without. Then, for each one, note whether you already have API credentials, whether that system has a well-documented public API, and whether you’ve actually checked that it supports the specific data flow you’re imagining.

This matters more than most founders realise. We’ve had briefs come in where the integrations section reads “Xero, Salesforce, and our existing internal system.” Xero is fine – good API, well-documented, we’ve built against it plenty of times. Salesforce can be a multi-week effort depending on what you’re syncing and which edition of Salesforce the client is on. “Our existing internal system” is often a legacy database with no API at all, which means we’re either building one or scraping it somehow. Those are three completely different cost conversations.

A useful format for each integration:

• System name and what you’re using it for
• Direction of data flow – push, pull, or both
• Frequency – real-time webhook, scheduled sync, or on-demand
• API documentation link if you have it
• Known gotchas – rate limits, authentication complexity, legacy format

If you can’t fill that in for an integration, say so explicitly. “We know we need to connect to our ERP but haven’t investigated their API yet” is a fine thing to write. It tells us to build a discovery phase into the proposal rather than guessing.

Data: What Exists, What You’re Keeping, What You’re Starting Fresh

If there’s an existing system being replaced, we need to know about the data in it. Not the full schema – just the shape of the problem. How many records? What format? Is there a clean export path, or is this a manual migration job?

We’ve seen data migrations that took longer than the actual build. A fintech we shipped last year had a reasonably clean CSV export from their old platform, but the currency handling was inconsistent across three years of records and had to be reconciled before anything could be imported. That wasn’t in the original brief. It wasn’t anyone’s fault – it just wasn’t thought about. It cost time we hadn’t priced for.

If you’re starting greenfield, say that too. “No existing data, we’re building from zero” is genuinely useful information – it removes a whole category of risk from the quote.

Be Explicit About Constraints

Agencies quote differently depending on what they know about your constraints. The three that matter most:

1. Timeline. If you have a hard launch date – a conference, a funding milestone, a customer commitment – say so upfront. Don’t bury it. It affects how work gets sequenced, whether we run things in parallel, and whether we need to phase scope to hit the date. A 28-day MVP is possible for the right scope; a 28-day deadline on a multi-integration platform is a different conversation.
2. Budget range. Yes, you should share it. “I don’t want to anchor the quote” is understandable but counterproductive. If your real budget is $60K, we should know that before we spend an hour scoping something that would cost $120K done properly. We’d rather have an honest conversation about what’s achievable than send you a proposal you have to reject. You don’t need to be precise – a range is fine.
3. Ownership and hosting. Do you want to own the infrastructure, or are you happy with a managed hosting arrangement? Do you need the codebase handed over, or is an ongoing retainer model workable? These aren’t minor points – they change how things get built and what gets priced.

What a Good Brief Actually Looks Like

You don’t need a 40-page document. The briefs that generate the most grounded proposals are usually four to eight pages covering:

• The problem you’re solving and who has it
• The primary user types and their key jobs to be done
• The core flows in plain language (not wireframes, not specs)
• What’s explicitly out of scope for version one
• Every integration, with the detail above
• Existing data situation
• Timeline constraints and hard deadlines
• Budget range
• Preferred engagement model – fixed price, time and materials, or hybrid

That’s it. Eight sections. You could write it in a Notion doc or a Google Doc. It doesn’t need to be formatted beautifully. It needs to be specific and honest.

The founders who come in with this prepared get better proposals faster, spend less time in back-and-forth clarification, and – critically – end up with more accurate quotes they can actually hold an agency to. The ones who come in with a vague paragraph and a vibe get variable numbers and a discovery phase tacked on the front of every proposal.

If you’re about to brief an agency and want a second set of eyes on what you’ve written – or you want to work through whether your scope is realistic for your timeline and budget – talk to Amora about your build. We’ll tell you straight what we think before anything gets signed.