How to Brief an AI App Studio
A brief for an AI app studio is a description of a job a person needs to finish. The model is a means. If your document starts with a vendor name or a demo you saw, you are briefing a feature, not a product. This article is about that document. It is not about why AI belongs in the stack. For that argument, read AI is an infrastructure, not a feature.
Brief an AI app studio with the user job, the data you can legally use, and the failures you will accept. Do not brief a model name and a vibe.
What belongs on the first page of the brief?
Four blocks. Who the user is. The job they are stuck on today. The inputs you already have. The output they will trust enough to act on. If you cannot fill those blocks, you are not ready to hire. You are ready to write a research note.
Croncode’s own apps are useful as examples of jobs, not as templates. YourStyle helps someone dress from clothes they own. Numira structures a life choice. Neither brief would start with “add ChatGPT.” Both would start with a stuck person. See the studio.
How do you describe data without handing over secrets?
Name the class of data, the owner, and the retention rule. “User closet photos, stored on device unless they opt in.” “Order history from our shop, 24 months, no payment PAN.” Do not paste production keys into a slide. Do not send a customer spreadsheet to a personal inbox.
- What the model may see.
- What must never leave the device or the region.
- What a human will review when the model is wrong.
Wrong answers are part of the product. Write three failure cases you can live with and one you cannot. Personalization that feels like watching is a cannot. We drew that line in AI personalization without creepiness.
When should AI be out of version one?
| Signal | Keep AI out | Put AI in |
|---|---|---|
| The job has a clear rule | Yes, use the rule | Only if the rule has too many exceptions |
| You have no evaluation set | Yes | After you can score outputs |
| A wrong answer harms a person | Yes, or add a human gate | Only with a review path |
Studios that agree to “AI everywhere” in week one are selling a demo. Ask them to put AI in a module you can turn off. That is infrastructure talk in briefing form. The longer case is in the infrastructure essay linked above.
What else should the studio receive?
The same packet you would send for any custom build: accounts, brand, languages, and a not-now list. Use what to send when requesting a software quote. If iOS is the surface, add the selection checks in how to choose a custom iOS studio.
If you are deciding process, do not hide it in the AI brief. Write a separate note on fixed scope vs agile for a first store release. Speed problems belong in time-to-market roadblocks, not in a model paragraph.
What mistakes waste the first workshop?
- Demo theater: a chat window that does not sit in the user job.
- Unowned data: scraping a source you cannot license.
- No offline path: the app dies when the model times out.
- English-only strings: if you will ship Turkish, say it now. See localization.
People who will read the brief at Croncode: Goktug Unver and Yusufhan Sokur. More posts: Journal.
Frequently asked questions
Should I name the model in the brief?
You can name a constraint, such as on-device only. Do not name a model as the product. Models change. The job should not.
Do I need a dataset before I talk to a studio?
You need a plan for evaluation. A small labeled set beats a large unlabeled dump. If you have neither, start with rules and collect.
Can the studio train on my users?
Only with a written rule and a consent path. Default to no. If you cannot explain it on a permissions screen, do not do it.
How long should the brief be?
If it is longer than a short memo plus appendices, you are writing a novel. Keep the first page to the four blocks.
Where can I see AI used as a job, not a badge?
Open YourStyle on the App Store and Numira, then read what Croncode builds.
