· Mobile

How to prepare a mobile app brief before development starts

A short brief that names the user, the first release, and the constraints will get a more useful estimate than a feature wishlist.

By Teramob Technologies

A useful app brief is not a long specification. It is a clear account of who the product is for, what the first version must let them finish, and which constraints are already known.

The person and the job

Name the person who will use the app in a normal week, not a persona invented for a slide. Then name the job they need to finish. "Customers book a visit and staff can see the day's list" is enough to start. "A world-class platform" is not.

If two groups use the product, say what each one does. A customer and a dispatcher rarely need the same home screen.

Scope for a first release

List the tasks that have to work on day one, and list the tasks that can wait. The second list is as useful as the first. It stops the estimate from covering a year of ideas.

For each task in the first release, note what "done" looks like. Booking a visit might mean choosing a time and receiving a confirmation. It does not have to mean payments, loyalty points, and a referral program.

Content, accounts, and integrations

Say who provides the words, images, and product data. A build stalls when the interface is ready and the catalog is not.

Also say who owns the Apple and Google developer accounts. They should belong to your company. A development partner can help you submit a build without becoming the account owner. The same is true of any backend, payment, or messaging service the app will call.

Constraints that change the estimate

Write down anything that limits the work: a minimum Android or iOS version, languages, offline use, an existing API, or a date that is tied to a real event. If there is no fixed date, say that too. An invented deadline makes the scope dishonest.

If you already have a design or a half-built app, include access to it and a note on what must be kept.

What to send

A page or two is enough:

  • Who uses it, and what they must finish
  • What is in the first release, and what is not
  • Platforms, languages, and known integrations
  • Who owns the store accounts and the content
  • How you will judge that the first version works

Mobile app development can start from that brief. The estimate that comes back should be able to point at it.

Have an idea worth building?

Tell us what you're planning. We'll help you explore the right approach for your product.

Discuss Your Project