A mobile app brief usually lists screens and leaves out the decisions behind them.

This is the web edition of our third whitepaper. The designed seven page version is on our LinkedIn page.

The problem: briefs describe screens, not work

When a business decides it needs an app, the brief that goes out to vendors tends to hold three things: a list of screens, an existing app the new one should look like, and a launch date. All three are easy to write down. None of them says much about the work the app is meant to carry.

What usually goes missing is everything around the screens. Who will use the app. Where those people will be when they do. Which spreadsheet, paper form or chat group it is there to replace. And what the business expects to add once the first release is in use. A vendor can build exactly what the brief asks for and still deliver something that does not fit, because the brief never described the job.

Why it is hard: every gap becomes a guess

Each missing answer does not disappear. It turns into a decision someone makes during the build, often without the business in the room. A few of those decisions shape the whole project.

  • Web or mobile. Whether a function belongs in a web app or a phone app depends on who carries the device. Office staff at a desk and a field team on the road need different things.
  • Sign-in. How people sign in decides how quickly staff and customers get started, and it is awkward to change once accounts exist.
  • Dependencies. Some functions need others in place before they work. Handling returns and refunds, for example, needs order management, customer accounts and inventory to exist first.
  • Phone-only features. Push notifications and barcode scanning live on the phone. If they are needed, the mobile app is no longer optional.
  • Release two. When nobody has written down what comes next, the first release is built without room for it, and growing later can mean rebuilding.

What good looks like: a brief written around the work

A useful brief starts from the work rather than the interface. It answers five questions in plain language.

  1. Who uses it. Staff, a field team, customers, or all three. Each group has different needs, and some may never see the parts built for the others.
  2. Where they use it. At a desk, on a phone, or out in the field. This decides what belongs in a web app and what belongs on the phone.
  3. The few jobs the business cannot stop doing. Not every function the business might one day want, just the ones that would hurt if they stopped tomorrow.
  4. The records that need to live in one place. Customers, orders, stock, appointments. Whatever is currently spread across files and message threads.
  5. What the second release should add. Even a rough answer lets the first release be built so the next one adds to it rather than replacing it.

None of this needs technical language. A business owner or operations lead can write it in an afternoon, and it gives any vendor far more to work with than a set of screen sketches.

How Mobilio approaches it: scope the app as modules

We scope client applications by module, one functional unit at a time, so the brief maps directly onto what gets built.

  • Every build starts from a base: sign-in and profile management, company information and a product or service catalogue.
  • The business then chooses three modules for the first release, such as appointments, order management, inventory or checkout.
  • The core is a web app. A mobile app is added where the work happens on a phone.
  • Features that only live on the phone, such as push notifications for order updates or barcode scanning for stock, are scoped into the mobile app where they belong.
  • The interface is designed for operational simplicity, in the client's own branding, so staff are not overwhelmed by it.
  • Delivery takes four to six weeks depending on complexity, and onboarding video walkthroughs and documentation ship with the build.

Because the system is built in modules, the second release adds modules to the same system. That is why it is worth writing down what release two might hold, even before release one starts.

What to ask a vendor: six questions to settle in writing

Whoever builds the app, ourselves included, these are worth agreeing on paper before work begins.

  1. Which modules are in release one, and which wait for later?
  2. Which features need the phone, and which run on the web?
  3. How will staff and customers sign in?
  4. Does any module we chose depend on one we did not?
  5. What do onboarding and documentation cover at handover?
  6. Which spreadsheet, form or chat group does the app replace?

A vendor who answers these clearly has understood the work. A vendor who goes straight to screen designs may be building from the brief you wrote rather than the business you run.

Where to start

Bring the work, not the wireframes. Tell us who will use the app, where they will be, and the jobs it has to do, and we will scope the modules from there.

Write to contact@mobilio.asia. Mobilio Asia works from Singapore, Ho Chi Minh City and Hanoi.