How to Brief a Product Studio and Get a Useful First Milestone

A brief is not a specification. Its job is to give a studio enough context to find the riskiest decision in your product and propose a small, bounded first step that tests it. Six facts on one page do that better than a forty-page requirements document.

Long specifications tend to fail in a predictable way. They describe features in detail and leave out the things that actually decide cost and risk: who the users are, what the product must connect to, and why the date matters. A studio reading one ends up pricing the document rather than the product.

A short brief also helps you. Writing it forces you to choose the first job the product must do well, which is the decision most early projects skip. If you cannot fit the goal on one line, the first conversation with any team will be about finding that line, and that is a useful conversation to have early.

This guide covers what to send, a template you can copy, how to read the proposal that comes back, the signals that separate good partners from risky ones, what the first week should produce, and how ownership should work from day one.

Send the goal, the users, the hardest constraint, the existing system, the deadline driver and a budget range. Each one changes the shape of the first milestone, so each one earns its place.

Two notes on the harder items.

The deadline driver matters more than the deadline. "We need it by March" gives a team nothing to work with. "A partner launches in March and we must be in their app" tells them which parts are fixed and which can move.

A budget range is not a negotiating weakness. Without one, a studio either proposes the version it would most like to build or the cheapest version that might work. With one, it can tell you what is realistic inside your range and what is not. The contact form on this site asks for a range, with "Not sure yet" as an honest option.

What not to send in a first message: credentials, customer records, health information or anything covered by a confidentiality obligation. Describe the shape of the data instead ("about 40,000 customer profiles with contact details and transaction history") and share the real thing later under an agreed process.

Copy this, fill in what you know and leave the rest marked as unknown. "Unknown" is useful information. It tells the studio where the first milestone should look.

``` PRODUCT BRIEF (one page)

1. Goal The one job the product must do well first: How we will know it is working (a behaviour, not a feature):

2. Users Who uses it, on which devices, in what setting: Who pays, if different: Roughly how many at launch, and in a year:

3. Hardest constraint The thing most likely to make this fail (an integration, a regulation, performance, hardware, data):

4. Existing system Code, designs, backend, data and accounts that already exist: What is working well, and what is not:

5. Deadline driver The date, and what happens if we miss it: What is fixed, and what could move:

6. Budget range A band, or "not sure yet": How the decision will be made, and by whom:

7. Unknowns What we have not decided, and what worries us most: ```

Keep it to one page. If a section runs long, the extra detail is usually a feature list, and feature lists belong in the first milestone, not the brief.

Two optional attachments help without adding pages: links to any existing product (store listings, a staging site, a Figma file) and one paragraph on why you are looking for an outside team now.

The first call is about fit and risk, not a sales pitch. A good studio spends most of it asking questions and ends it by naming the decision that matters most, or by telling you it is not the right team.

Our own process runs in four beats: fit and risk at the start, a bounded first milestone agreed in week 1, visible work every week, and a handover your team can own. Whoever you hire, expect something with the same shape. The questions a serious team asks in that first call tend to sound like these:

• What happens today without this product? Who feels the pain, and how often?
• Which part of the brief are you least sure about?
• What already exists that we must not break?
• Who decides when the first milestone is done, and what will they look at?
• What would make you stop the project?

Notice what is missing: a framework recommendation in the first ten minutes. If a team tells you which technology you need before it understands your users and constraints, it is selling the technology it already uses. A fair technology comparison comes after the risk is clear. Our Flutter decision guide is an example of the kind of reasoning to expect, including when the answer is not Flutter.

You should leave the call knowing three things: what the team thinks the biggest risk is, what a first milestone would contain, and what they need from you to propose it.

Judge a proposal by the shape of the risk it hands you, not only by the total. Fixed scope, time and materials, and milestone-based pricing put uncertainty in different places, and each one fits a different stage of knowledge.

A worked way to compare them, using illustrative figures only:

• A fixed bid on uncertain scope is roughly estimate × (1 + contingency). If the estimate is 40 working days and the studio adds 30% for unknowns, you pay for 52 days whether the unknowns appear or not.
• Time and materials is days actually used × day rate. If discovery shows the job is 35 days, you pay for 35. If it shows 70, you pay for 70, which is why it needs a review point.
• Milestone pricing caps your exposure at one milestone at a time. A wrong direction costs you the first milestone, not the project.

Whatever the model, a proposal is incomplete if it does not name all six of these:

1. The outcome: what will be true when the milestone ends.
2. The exclusions: what is deliberately left out.
3. The team: named roles and how much of their time you get.
4. The timeline: dates for demos and for the end of the milestone.
5. The acceptance evidence: what you will look at to agree it is done.
6. What could change the estimate: the known unknowns, stated up front.

If a proposal is missing one, ask for it before you sign. The answer tells you as much about the team as the proposal does.

The strongest signal is how a team talks about risk and ownership before it has your money. Teams that are candid about uncertainty and insist you own your accounts tend to stay candid when things go wrong.

Red flags

• A fixed price for a vague brief, returned within a day. Either the scope has been guessed or the contingency is large. Ask which.
• No exclusions. Every proposal leaves things out. If none are listed, you will discover them as change requests.
• The studio wants to own the repository or the app store account "for convenience". Convenience for whom?
• No working software until late in the project. Months of design and "architecture" with nothing running is how projects disappear.
• Seniority at the pitch, juniors on the work. Ask who will write the code and whether you can meet them.
• Every answer is yes. A team that never says "that is a bad idea" or "we are not the right fit" is not reading your brief closely.
• Case studies with numbers that cannot be checked. Public products have store listings and websites. Claims you cannot check should not carry weight.

Green flags

• They argue with the brief. Good teams push back on scope, the order of work, or the problem itself.
• The first milestone is small and ends in evidence, such as a released journey, a proven integration or a written audit.
• You get repository access from day one, and progress shows up as commits, demos and written decisions rather than status slides.
• New scope arrives as a trade-off ("this adds a week, or we drop X") instead of a surprise invoice.
• They describe their own past scope precisely. On our Work pages, for example, each case study says which part of the product we were responsible for, and states that public download figures describe the product's scale, not results created solely by our team. That precision is worth looking for anywhere.
• They talk about handover before you raise it.

By the end of the first week you should be able to point to written agreements, real access and the first technical evidence. If week 1 produces only meetings, the project has started in the wrong mode.

A good first week produces:

1. A written milestone. One or two pages: the outcome, the exclusions, the team, the dates and the acceptance evidence. Both sides should be able to judge "done" without a debate.
2. A repository in your organisation, with the studio added as collaborators, a first commit and an automated build. The code lives with you from the first line.
3. An access list. Every account the project touches (cloud, app stores, analytics, third-party APIs), who owns it and who has access. Owners should be people in your organisation.
4. A short risk list. The top five things that could derail the milestone, each with a first action and an owner.
5. First technical evidence on the biggest risk: a spike against the partner API, a prototype on the target device, or a finding from the existing codebase.
6. A decision log with its first entries, such as why a platform or library was chosen and what was ruled out.
7. A date for the first demo, inside the milestone, on real devices or a real environment.

Not every item needs to be finished on day five. The access list may still have gaps, and a spike may need another week. But each should exist and be visible to you. If you are taking over an existing product rather than starting fresh, the first two weeks look different; our codebase takeover playbook walks through them.

You should own the product from the first commit, not at the end. Repositories, cloud accounts, app store accounts, domains and analytics belong in your organisation, with the studio given access. It should never be the other way round.

Settle four things before work starts:

• Code and IP. The agreement should assign the work product to you. Where a studio brings pre-existing libraries or tools, the agreement should name them and grant you a licence to use them in your product, including after the engagement ends.
• Open-source components. Ask for a list of open-source dependencies and their licences at handover, so your legal team is not surprised by a copyleft licence later.
• Accounts and secrets. Signing keys, store accounts and production credentials should be created in your accounts, stored in a vault you control and shared on a least-privilege basis. Losing access to an Android upload key or an Apple developer account is one of the most expensive and avoidable takeover problems.
• The exit. Write down what happens if you stop working together: how work in progress is finished or parked, how open decisions and known issues are documented, and how access is handed back.

This is not legal advice, and your agreement should be reviewed by your own counsel. The engineering test is simpler: could another competent team pick this product up next month without the studio's help? If the answer is no, ownership has not really transferred, whatever the contract says.

Handover itself should be a process, not a final meeting. Documentation, architecture diagrams, decision records and release runbooks build up during the project, and your engineers pair on the hard parts while the studio is still there to answer questions.

Once the one-page brief exists, sending it is the easy part. Send the same page to every team you are considering, so you can compare how each one responds to the same facts.

A practical sequence:

1. Write the brief using the template above. An hour is usually enough.
2. Send it to two or three teams. More than that turns evaluation into a project of its own.
3. Take the first call and listen for the questions they ask, not only the answers they give.
4. Compare proposals on the six required items and on the risk model, not just the total.
5. Start with one milestone. Judge the team on what it delivers, then decide what comes next.

If you would like us to be one of those teams, our contact page asks for much the same information as the template: the type of project, a budget range, a timeline, and what you are building, fixing or scaling. Paste your brief into the last field. If your product is an AI feature, the AI product development guide lists what to include. And if we are not the right team for it, we will say so in the first call.

How long should a software project brief be?

One page is enough for a first conversation. It should cover the goal, the users, the hardest constraint, the existing system, what drives the deadline and a budget range. Detailed feature lists are better worked out together during the first milestone than written up front.

Do I need a full specification before contacting a development studio?

No. A clear description of the user, the problem and the main constraint is enough to start. A good studio will help turn that into a scoped first milestone, and many detailed specifications have to be rewritten once real users and integrations are involved.

Should I tell an agency my budget?

Yes, as a range. A budget range lets the team shape a first milestone that fits, and tell you early if your goal is unrealistic for the money. Without one, proposals are hard to compare because each team is guessing at a different version of the product.

Is fixed price or time and materials better for app development?

It depends on how well the work is understood. Fixed price suits a clearly defined job but includes contingency for unknowns, while time and materials suits discovery but needs review points to avoid drift. For most new products, pricing one milestone at a time balances the two.

Who owns the code when an agency builds my app?

You should, and the agreement should say so explicitly. Repositories, cloud and app store accounts should sit in your organisation from the start, and any pre-existing libraries the studio brings should be named and licensed to you. Have your own counsel review the terms.

What should the first week of a software project produce?

A written milestone with outcome, exclusions, team, dates and acceptance evidence; a repository in your organisation with an automated build; an access list; a short risk list; first technical evidence on the biggest risk; and a date for the first demo.