An app development brief you can send for a quote

Before asking for an app quote, write down who needs it, what they need to do, and how you will check that it works. Then list what the first version can leave out.

Use the app development brief template below in a document or email. Write “unknown” where you need advice. Ask each developer to quote against the same brief and state what they have assumed.

Copy these prompts into your brief

The job: Who will use the app? What do they need to get done? How do they do that job now, and where do they get stuck?

The main task: Describe the steps from opening the app to finishing that job. Include what the person should see at the end.

The first version: List the tasks it must support at launch. Put ideas that can wait in a separate “later” list.

Where it must work: Name the phones, tablets or computers your users have. Say if they need to work without an internet connection. If you are unsure whether you need a website or a store app, leave that choice open.

Records and access: List what the app must save. Say who can view, change or delete each kind of record. Use made-up sample records in the brief; leave out passwords and real customer details.

Other systems: Name any software it must connect to. Say what needs to move between the systems and who can check how that connection would work.

The test: Write what you would need to see in a demo before you could accept the work. Include a mistake a user might make and what should happen next.

Budget, dates and support: Give your own spending limit and any firm date, with the reason for it. Ask what the quote includes after launch, what costs recur, and who owns the hosting or app-store accounts and source code.

Finish with a list of questions you need the developer to answer. You do not need to choose a programming language to describe the job.

Start with the problem you have seen

Try to give a real example of the current problem, with private details removed. If you have not spoken to the people who would use the app, mark their needs as assumptions to check.

The UK Government Service Manual’s guidance on user needs makes this distinction: needs should come from research with users and focus on their problem, rather than a chosen solution.

For your brief, write “staff need to see which booking requests still need a reply” before deciding that they need a new mobile app. Ask the developer whether your current tools could do that job.

A worked booking brief

This is a made-up example to show how to fill in the prompts. It is not a client project, tested app or quote.

The job: A small repair shop wants staff to handle booking requests from its website in a shared list. Today, staff copy requests from email into a diary. For this example, assume the owner has seen staff miss requests during that step.

The main task: A visitor chooses a repair type, enters contact details and asks for a date. The screen says the request was sent and the date still needs staff approval. Staff then open the list and mark the request as “replied”.

The first version: Accept a request and show it to staff. Let staff mark it as replied. Staff will still confirm dates by phone or email. Leave online payment, automatic reminders and a customer account for later.

Where it must work: Visitors use a phone browser. Staff use a browser on the shop computer. The first version needs an internet connection. Ask whether a form on the current website can meet this brief.

Records and access: Save the repair type, requested date, name and contact details. Visitors should not see other people’s requests. Staff need to see the shared list. Agree who can remove a record and when it should be removed before work starts.

Other systems: No link to the shop diary in this first version. Staff check the diary before they confirm a date. Ask how staff will sign in to the shared list.

The test: Send a sample request. Check that it appears once in the staff list with the same details. Mark it as replied and reload the page; the mark should remain. Try to view that list without signing in; access should be refused.

Also try a request with no contact details. It should explain what to add. If a request fails to send, the screen should say it failed and offer a way to try again. These are proposed tests to agree with the developer, not claims about a built system.

Budget, dates and support: The shop owner must fill in their own limit and date. Ask for ongoing charges and support terms as separate lines in the proposal.

Make “done” something you can check

“Easy to use” leaves the test open. “A staff member can find a new request and mark it as replied” names a task you can watch.

Developers call these checks acceptance criteria. The Service Manual’s guide to user stories describes them as outcomes used to check whether a service meets a user need.

Use plain sentences in your brief. For each main task, add a successful result and a failure case. Ask the developer to explain how they will test those checks and which devices the quote covers.

A working demo answers whether the agreed task works. Keep a separate question for users: does it solve the problem they had? Neither a brief nor a demo is proof of demand or future sales.

Read the quote against the brief

Keep the brief beside each proposal. Check which tasks are included, which are left out, and which still need research. Ask for the cost of that research before approving it.

If a proposal adds a store app, an account system or an AI feature, ask which task needs it. If it drops a requirement, ask what users will do instead. Keep the final agreed brief with the quote so later changes have a clear starting point.

For the wider buying decision, see our app developer NZ service page. You can also view the studio’s published work.

Bring us the brief, or start with your site

For a new app, email the studio with the job you need done and your open questions. A short draft is enough to start that conversation.

If the problem is on a website you already run, you can request our free website check. That offer covers a review of the public site; it is not a full app specification or a check inside private accounts. Enter the page address in the form. Use its optional question to describe the task your visitors struggle to finish.