How to write a mobile app brief.

How to write a mobile app brief.
AutorIlona LeoniewskaMaj, 2022

When You decide to create a mobile app, we should base it on the clarified goals and business needs. The mobile app should have a proper biref.

When you want to know how much your project will cost and you want to get a more specific answer than the "50.000-500.000 PLN" range, your request for proposal should be more precise.

The following approach won't work: "I need a quote for an application similar to Tinder, but for B2B customers". So how to formulate a question about the price of the application? Below you will find some tips on what to include in the brief to get the most accurate answer.

Let's introduce ourselves, that is the introduction to the app brief

Why is it worth saying a few words about your company if you are not Walmart, Shell or Volkswagen? If the development studio, to which we will turn with a query, will know whether the planned application is part of our core business, or it is our side project (spin-off), it will be able to suggest different solutions. They can directly influence the production costs. An example is the change of technology, for example from native to PWA or the choice of priority features.

Show us the environment

In this section it is worth describing a few elements that influence the design of the application:

  • Who is your customer? Persona, customer profile (age, position, type of work, etc.), these elements are especially important at the stage of UX and graphic design.
  • If we have conducted market research, related to the project, it is worth presenting the conclusions (if they are relevant from the point of view of the customer and the business model).
  • Who are your competitors? Give specific examples. Are the competitors indirect, or are they direct? (offering the same type of service/product)?
  • In which markets do you plan to operate? Domestic market only or also abroad (which countries)?
  • Legal aspect - do you need to obtain various certificates from external institutions?

The answers to these questions will allow the team to estimate the project. The more details you provide, the more accurate the estimate will be.

The better the project goal, the better the mobile app brief

On the surface, the point seems to be obvious and trivial, but we know many cases in which the originator of the app wanted to achieve a lot, and in practice achieved nothing. In most cases, the goal is profit - a clear financial category that does not need to be explained. However, in creating a mobile app you need to define what the app is supposed to facilitate, what problem it solves.

For Duolingo type of application it is important to learn foreign languages, for SofaScore: checking live sport scores, for Orlen Pay - enabling to pay for fuel directly at the pump.

Subordinating the whole project to a specific goal will cause the developed user stories of mobile applications to shorten the user's path from launching the application to fulfilling the need.

If you want to achieve additional brand marketing and communication effects, emphasize it at this stage. Example: Orlen Pay. The app is not an end in itself. Its purpose is to build the image of a company that is open and meets the needs of its customers. Customer understands the meaning of this assumption when he refuels at Orlen, is in a hurry and there is a queue of people waiting for hot dogs.

Get a free mobile app brief!

* field field required

Check approval:

You can unsubscribe at any time by clicking the link in the footer of our emails. Information about our privacy practices can be found on our website.

We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your data will be passed to Mailchimp for processing. More about Mailchimp policy privacy.

Mobile app brief and integrations

Sometimes it may turn out that the application, must work with other systems. Often there is a top. Cash system, HR system, university or warehouse system. Such information must be included in the brief, because it can be quite an important part of the whole investment. Everything depends on the scope of integration or available external API. So when writing about integrations, let us indicate what data we exactly need from selected systems, how often we want to update the information and whether these systems are our property or external.

Scope of Functionality

Many queries immediately go to this point, which is the list of app functionalities. To begin with, it is useful to know what elements a mobile app consists of:

  • Native application for iOS and/or Android
  • UX/UI design and graphic design
  • Functional and technical specification of the project

You also need to set aside resources and time for testing and project management. If the management is done efficiently, it will have a decisive impact on the app deployment time. Enter this in your brief and the mobile app will be clearer.

Sometimes it happens that the client has the specification, API or graphic design but needs a studio to program the app. So if a graphic designer in your company can take care of the graphic design, put it in the brief.

Let's analyze an example. We will deal with a situation in which the task will be to implement the entire project. You should point out that you do not have materials, directly related to the application, so you expect the agency to provide:

  • Functional and technical specification of the project,
  • Graphic design,
  • CMS/API,
  • Native apps for both mobile systems,
  • Often also: joint workshops with the team creating the application.

Apart from the purely technical and creative issues, it is worth indicating whether you expect the development studio to participate in the preparation of the business concept (BRD - Business Requirements Document). It is important because the remaining two elements, that is FRD (Functional Requirements Document) and TRD (Technical Requirements Document) are often in the bigger part on the side of the developer.

When is it worth to ask for it? When we do not have the final concept of the project and we are looking for inspiration about mobile possibilities. In such a situation development studio often offers to organize workshops, where the application project is drawn up together and discussed on a whiteboard in a comfortable and clear way for everyone.

Preparing a list of functionalities is not a simple matter. Some of the indicated functionalities result in several additional necessary screens. Here are some examples:

  • The application is supposed to allow issuing invoices and sending them to contractors. In this case, in addition to the functionality of issuing a document, you will need:
  • Registration/login of the user who wants to issue an invoice
  • If we have the option of registration and logging in, "My profile" has to appear in the application, which can be edited
  • Entering company data (specified list of fields)
  • Optionally adding your own logo to the document
  • Saving the history of issued invoices with the information about their status
  • Server-side activities (CMS) to manage users
  • Using the application, users can invite each other to contact them and after mutual acceptance, they can chat with each other. Such functionality also entails multiple screens and several scenarios:
    • User registration/login
    • If we have the option of registration and login, then "My Profile" must appear in the application, which will be editable
    • Creation of user lists (from which you will be able to select the user you want to invite)
    • Handling the user database on the server side (CMS)
  • Scenarios:
    • What happens if the invited user accepts the invitation - the chat screen launches
    • What happens if the invited user rejects the invitation - the inviting user should receive a message with the reason for rejection
    • Can the user rejecting the invitation type the reason for rejection himself, or select it from a list?

At this point it is worth to emphasize one more important model of functionalities presentation Some of them are must-have for us, and some of them may only appear. Adding priorities next to functionalities will help in estimating budget for now and for the future. When prioritizing, it is useful to use the simple but very effective MoSCoW method:


  • M - must have
  • S - should have
  • C - could have
  • W - won't have (would like to)

Budget and schedule also belong to the elements of the application brief.

It is necessary to talk about money and time, because these two variables ultimately decide the shape of our project. While writing a brief, you will most often encounter three scenarios of how a mobile application is created:

  • Fixed time - a situation in which a specific, impassable deadline for implementation, so the software house should receive information in the brief that, for example, the application is to be implemented and made available to users by a deadline of, for example, December 24, 2021.
  • Fixed scope - a situation when you have a predefined set of functionalities that cannot be changed. A change may affect the security or execution of the core tasks of the application. For example, banking or medical or accounting applications. If such a situation applies to your project - list all the functionalities that must be unconditionally implemented.
  • Fixed price - you set a predetermined amount of money to spend. This is the budget that you cannot exceed. Indicating this budget in the brief will allow the development team to prepare a proposal for pricing and a set of functionalities to fit the indicated budget.

It is possible that all these variants may occur simultaneously or in sets of two, e.g. when I have a specified budget and a deadline. A full-fledged brief has as much accurate information as possible.

Summary, or what is a good mobile app brief?

If you want to get a precise quote, which will not be contained in the fork: 50.000-500.000 PLN net it is worth taking care that the brief, which describes how the mobile application is to look like, has as much information as possible. Above I presented everything that will allow both interested parties, i.e. the client and the supplier, to shorten the time of talks preceding the realization of the project. 

Many things are known in advance, so there is no need to send many emails with additional questions, waste time answering them and thinking and assuming several implementation scenarios. 

The most important thing, however, is that by writing an accurate and precise brief you can get an accurate and precise schedule and budget for the project, and after all, that's what you want, right?