How to write an app brief before your first builder prompt

The first version of an app often becomes too large before anyone has used it. A simple tracker acquires payments, notifications, a social feed and an analytics dashboard. Soon, you are trying to fix five unfinished workflows at once.

An app brief gives the first version a boundary. It describes the person you are helping, the job they need to finish and the checks that show whether the app helps them finish it. You can use the brief with Alia to prepare instructions for your chosen AI app builder.

Below is a worked example for a community workshop's equipment loan tracker. It is an illustrative planning exercise, not a finished product or a claim about a customer's results.

1. Name the user and the problem

Start with a sentence that somebody outside your project can understand:

Workshop staff need to know which tools are available, which have been borrowed and which have been returned.

This is more useful than “an equipment management platform”. It tells you whose view matters and what the first version needs to make easier.

Before building, check the assumption with the people who would use it. How do they record loans today? What gets missed? Would a shared spreadsheet solve the problem? If an existing approach works well, understanding that is valuable too.

2. Choose one complete workflow

For this example, the first workflow is:

1. View the equipment list.
2. Choose an available item.
3. Record a loan.
4. See the item marked as borrowed.
5. Mark it returned and see it become available again.

The important word is complete. A small working loop teaches you more about the idea than several attractive screens whose buttons do nothing.

Ask Alia to challenge the scope. If a proposed feature does not help someone complete this loop, put it in a later-version list rather than adding it to the first build.

3. Describe the screens and information

You do not need to design a complex database to explain the information your prototype needs:

For a prototype, use invented sample records. Real borrower details introduce privacy and access requirements that should be designed and checked before launch.

Also describe the empty and error states. What appears before the first loan? What should happen if the same unavailable item is selected twice? If saving fails, how will someone know?

4. Write checks you can actually perform

“Make it work properly” leaves too much unstated. Write observable checks instead:

• Borrowing an available item changes its status.
• An item already on loan cannot be borrowed again.
• Returning an item restores its availability.
• Required fields show a useful message when left empty.
• Refreshing preserves saved loans if persistence is part of this stage.
• The main workflow fits a phone screen without sideways scrolling.

These checks are a starting point, not a complete test plan. Before a real launch, add checks for actual accounts, permissions, data storage and recovery.

5. Turn the brief into a staged builder prompt

Here is an example of a first instruction you could adapt:

Create a mobile-friendly prototype for a community workshop's
equipment loan tracker.

User: a member of workshop staff.
Goal: record one equipment loan and mark it returned.

Use fictional sample equipment and borrower names.
Include an equipment list, a loan form and a current-loans view.
Show available and borrowed states clearly.
Prevent an already-borrowed item from being lent out again.
Explain which parts are simulated and whether data persists
after refreshing.

Keep this first stage to the loan-and-return workflow.
Do not connect real payments, send email or use real customer data.
Describe what you will build and any important missing decisions
before changing the project.

Tell Alia which builder you are using when you develop this instruction. Check the builder's own documentation for current controls and supported features. Lovable's guidance recommends scoping changes and explaining what should remain untouched. Replit's guidance also emphasises specific instructions, relevant context and incremental work.

6. Bring back evidence, not just “it is broken”

If the prototype behaves differently from the brief, describe the mismatch before requesting another large change:

Expected: after I return an item, it appears as available.
Observed: it still says borrowed until I refresh the page.
Steps: borrow an item, open current loans, choose Return.
Builder: [name].
Here is a screenshot and the relevant error, if any.

Help me understand the likely causes and write one focused
instruction for the builder. Distinguish evidence from guesses.
Preserve the working loan form and existing layout.

This is an example troubleshooting prompt. Alia can reason about what you supply, but she cannot confirm an unseen fix. Apply the instruction in your builder and repeat the relevant checks.

A reusable app brief

Copy this template into Alia and fill in what you know:

Working name:
Who it is for:
Problem they have:
How they handle it today:
One task the first version must complete:
Screens needed for that task:
Information each screen needs:
What happens when something is empty or fails:
What belongs in a later version:
Checks that show the first version works:
Chosen builder:
Questions or assumptions still unresolved:

Keep your brief current as you learn. If you change the target user or main workflow, update the brief before asking the builder to keep adding features.

New to the process? Start with what vibe coding means. Ready to shape your own first version? Bring your idea to Alia.