Powstania Warszawskiego 15
31-539 Kraków
The quality of the offers you receive depends far more on your brief than on the agencies you send it to. A good brief fits on two pages, says nothing about technology and a lot about your business. This guide shows what to put in it, what to leave out, and what a good agency should do with it next.
To brief an app development agency, write one to two pages covering the business problem, who the users are, the one thing the first version must do, the systems it connects to, what is out of scope, a budget range, a deadline and who decides on your side. Leave out technology choices and long feature lists. Send the same brief to every agency you consider, so the offers can be compared, and expect a good agency to answer with questions about your business before it gives you a price.
Founders and managers often hold back from contacting agencies because they think they need a full specification first. They do not. Three different documents get mixed up, and only the first one is your job before the first call.
One to two pages about the problem, the users and the goal. Written by you, before any conversation. Its job is to start the right discussion.
Screens, flows, rules and integrations in detail. Usually written with the agency after discovery. It is what a fixed price is priced against.
A formal request for proposals with evaluation criteria, common in larger companies and public tenders. Useful for procurement, often too rigid for a first version.
If you already have a detailed specification, send it. If you do not, a brief is enough, and our guide on writing a mobile app requirements document covers the next step.
Eight short sections cover everything an agency needs to understand your situation and propose something sensible. Most take a few sentences each.
Notice what is missing: screens, technology and a complete feature list. Those come later, and writing them too early tends to lock in decisions that should have been questioned.
Here is what a complete brief can look like for a fictional service company. It is short on purpose.
Problem. Our 25 technicians receive jobs by phone and text, write notes on paper and send photos through a messaging app. The office retypes everything into our invoicing system, which takes one person most of the day and causes billing errors every week.
Users. Technicians on Android and iPhone, often in basements without signal. Two dispatchers in the office on desktop computers.
Version one must. Let a technician see today's jobs, record work done with photos and a customer signature, and close the job so it appears in the office immediately.
Success. No retyping of completed jobs, and invoices sent the same day.
Systems. Our invoicing software, which has an API. Customer data currently lives in a spreadsheet.
Out of scope for now. Customer facing app, route optimisation, stock management, a Spanish version.
Budget and timing. A range for the first version, live before our busy season in spring.
Decision maker. The operations manager, available for a weekly call.
From this, a good agency can already tell you whether the first version is realistic for your budget, what it would leave out, and what it needs to check about the invoicing integration. If your situation looks like this one, our guide on internal business apps vs SaaS tools covers how to measure the workarounds first.
A brief gets worse, not better, when it tries to do the agency's job. These are the most common things that lower the quality of the offers you receive.
The response to a brief tells you more about an agency than its portfolio. Pay attention to the first questions you get back.
Questions about your business: how the work runs today, what happens when something goes wrong, who pays, which rule decides an edge case. Then an honest view on what fits your budget and what should wait.
Questions only about technology, or an immediate price with no questions at all. When we take over projects that went wrong elsewhere, the cause is almost always a supplier that never understood the operation.
After the first conversation, the brief should turn into a written scope: screens, flows, integrations and an explicit list of exclusions. That document, not the brief, is what a fixed price app development offer should be attached to. If the scope is still unclear at that point, a short discovery workshop closes the gap before anyone commits to a number.
It is normal to brief more than one agency, and the brief is what makes their answers comparable. Three habits help.
The most common delays in app projects come from the client side, and they are predictable. Starting these early can save weeks later.
With these ready, an agency working end to end can move from scope to a first build without waiting on paperwork. If you are planning a first version for a startup rather than an internal tool, the MVP development for startups page describes how that first version is scoped, and current price ranges are on the pricing page.
The business problem, who the users are, the one thing the app must do in its first version, the systems it has to connect to, what is deliberately out of scope, your budget range, your deadline and who makes decisions on your side. Two pages is enough. Screens, technology and a long feature list are not needed at this stage.
One to two pages. A brief is meant to start a conversation, not replace it. If it runs longer than that, it is usually turning into a requirements document, which is better written together with the agency after the first call.
Yes, as a range. Without it, an agency has to guess which version of your idea to propose, and you receive offers that are impossible to compare. A range lets the agency tell you honestly what fits and what has to wait for a later stage.
No. Describe the users, the devices they use and any constraints such as offline work or an existing team that will maintain the app. Choosing the technology is the agency's job, and a good one will explain the choice in writing.
A brief describes the business problem and the goal before the first conversation. A requirements document describes screens, flows, rules and integrations in detail, and is usually written after discovery, together with the agency. A fixed price is priced against the requirements document, not the brief.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Send it as it is. We will reply with the questions that matter for your business and an honest view of what a first version could include.