The brief of a new App

Every new App in AI App Design starts with a brief: a short, clear agreement on what the App must solve and what version 1 contains. You describe the idea in your own words, the AI drafts the brief, your team reviews it step by step, and the decision maker approves it. Only then is the App built from exactly the approved text.

Start it

1. In AI App Design, click Build a new App.
2. Give the App a name and describe the idea: who uses it, what they struggle with today, what it costs, and what should change. Choose a client if the App is for one.
3. Click Start the brief. In about a minute the AI drafts all 11 steps and lists the questions it most needs answered.

The 11 steps

Each step shows the questions to think about, and what is still missing. Polish with AI tidies one step without adding features you did not ask for; Undo puts back what you had. Your work is saved every time you move to another step.

1. Problem statement: who struggles with what today, what it costs, how often, why now, and what was already tried.
2. Users and stakeholders: every type of person involved, and what each needs.
3. Goals and success metrics: 2 to 4 goals, each with a number and a date.
4. Definition: the solution in one paragraph anyone can read, and the main journey in 5 to 7 steps.
5. What we do (MVP): every feature with its priority (Must, Should, Could, Won't). Only the Must features are version 1.
6. What we do NOT do: explicit and specific. This list prevents most disputes later.
7. Assumptions, constraints and risks: what we believe but have not checked; fixed limits (budget, deadline, technology, GDPR, hosting, languages); what could go wrong and the fallback; open questions, each with an owner and a due date.
8. User stories and acceptance criteria: every Must feature becomes one or more stories ("As a … I want … so that …"), each with criteria anyone can check with a yes or a no.
9. Data, integrations and requirements: data, integrations, platforms, languages, security and privacy, performance, availability, accessibility.
10. Milestones and deliverables: the dates of Brief signed, Design, MVP beta and Launch, and what is delivered at each.
11. Roles and change control: the decision maker, the business analyst and the tech lead, all from your team.

Review and send

The last step shows the brief exactly as the decision maker will read it and exactly what the App will be built from. It can be sent once every step is complete; anything still missing is listed with a link to its step.

Sending it creates the project the App is built in:

• you lead it; Marvin, the decision maker, the analyst and the tech lead are members (and the client, if you chose one);
• its milestones are the four dates of step 10;
• the decision maker gets the task Approve the brief;
• Marvin gets one task per build step (understanding the brief, planning, records, screens, tests…), ticked off automatically while the App is built;
• you get one task per user story, with its acceptance criteria as a checklist, to check in the finished App; and the task to publish it at Launch.

The decision maker's answer

The decision maker gets a notification and opens the brief (they do not need to be able to design Apps). They either click Approve and send to the client to sign, or send it back with what to change. A brief sent back opens again for you with their comment; change it and send it again the same project is kept.

The client signs it

In Review and send you choose who signs for the client: one of the client's contacts, or when the App has no client in NIZU a name and an email address. Once the decision maker approves, that person gets an email with a link (it works once, for 30 days). On the page it opens they read the brief, write their name, draw their signature with the mouse or a finger, confirm they agree, and sign. If something should change, they say so on the same page instead: the brief comes back to you with their comment.

When it is signed:

• the signed brief becomes a PDF the brief, the signature, who signed, when, from which IP address, who approved it for the team, and a fingerprint (SHA-256) of the exact text signed;
• the PDF is emailed to the client and to the stakeholders (you, the decision maker, the analyst and the tech lead), and can be downloaded from the brief;
• the App is built in the background from exactly the signed text, tested (every form is filled in and saved), and saved as a draft for you to check against the user stories before you publish it.

If the link is lost or expires, Send a new link on the brief sends a fresh one; the old one stops working.