Ask three developers to quote "an app for our business" and you will get three numbers that cannot be compared, because each one guessed at something different. A clear app development brief fixes that. It does not need to be technical or long. It needs to say who will use the software, what they must be able to do, which systems it connects to and what happens after launch. Here is how to write one for a web application, a mobile app or both.

What an app development brief should cover

Think of the brief as a map for the first conversation, not a contract. Two to five pages is plenty for most projects, and it should cover:

  • The problem. What is slow, error-prone or impossible today? "Quotes take two days because prices live in three spreadsheets" is more useful than "we need a quoting app".
  • The people. Who will use it, roughly how many, and on which devices.
  • The goal. What will be different when it works: fewer phone calls, faster invoicing, jobs no longer lost between the office and the field.
  • Constraints. Deadlines that are real, a budget range and systems that cannot change.

Whether you call the result custom software or custom web and mobile applications, the brief is the same document, and it is the best preparation for a first meeting with any developer.

User roles and the tasks that matter

Most business software has a handful of user roles, each seeing different things: an administrator who manages settings, office staff who handle records, field workers with a phone and perhaps customers who log in to a portal. For each role, list the five to ten tasks they will do most often, in their own words. "A technician marks a job done and adds photos" is a task; "job management module" is not.

Note who must not see what. Permissions are far easier to design at the start than to bolt on after launch.

Must-have features, later features and acceptance criteria

Split the feature list into must-have features for the first release and everything else. The first release, often called a minimum viable product, should be the smallest version that real users can work with every day. Later features are easier to rank once people are using it and telling you what they miss.

For each must-have feature, add acceptance criteria: a sentence that says how you will know it works. "When a customer uploads a document, the office sees it in the job record and gets a notification" can be tested; "easy document upload" cannot. Acceptance criteria are also the fairest way to settle whether a feature is finished.

Data, system integrations and devices

  • Existing data. What must be imported from spreadsheets or an old system, and how clean it is.
  • System integrations. Accounting, CRM, payments, email, maps or shipping. Name the software and the direction data flows; many of these connections are handled as API integration work alongside the app itself.
  • Devices and conditions. Office desktops, personal phones or rugged company handhelds; indoors or on job sites with poor signal. If people must work offline, say so, because it shapes the whole design.
  • Phone features. The camera, barcode scanning, location or push notifications point toward an app installed on the device rather than a web app.

A bespoke web application that runs in the browser is often enough for office tasks, while a bespoke mobile app earns its place when the phone's hardware or offline work matters. The brief does not need to decide this; it needs to supply the facts that do.

Accounts, ownership and life after launch

Ownership questions are easiest to answer before any code exists. The brief should state that the code repository, hosting, domain and app store accounts belong to your business. Publishing on the App Store under your company name means enrolling as an organization, and Apple requires a legal entity and a D-U-N-S number to verify it; see Apple's enrollment requirements. Google Play verifies organization accounts as well, so start both early.

Also plan for the years after launch. Phone operating systems get a major update every year, and store apps need updates to keep up. Custom mobile solutions and web apps alike need hosting, security updates and someone responsible for them, so ask in the brief how updates and support will work. In our custom application projects, documentation, access to the code repository and a plan for updates and hosting are part of the handover.

Frequently asked questions: app development brief

How detailed does the brief need to be?

Detailed enough that two developers would picture the same software. Describe tasks and outcomes rather than screens and technologies; a good developer will turn that into a design and ask about the gaps.

Should I put a budget in the brief?

A range helps. The same goal can be met with a lean first version or a fully featured one, and a range lets developers propose a scope that fits instead of guessing.

Do I need wireframes before contacting a developer?

No. Rough sketches or screenshots of tools you like are useful, but you do not need to design screens yourself. In our projects, clickable screens for the main tasks come after discovery and are reviewed with the people who will actually use the software.

Have a process that has outgrown spreadsheets? Our custom web and mobile application development service starts with discovery and a clickable prototype, builds in stages and hands over documentation and access to the code, for companies in Los Angeles, Long Beach and beyond. Send us your brief, even a rough one, and tell us who will use the software and which systems it has to work with.