Write for a builder, not an investor
A useful app brief is not a pitch deck. It should make the next build action obvious. Describe the user, the moment of use, the one promise, and the smallest product that can prove the promise in TestFlight.
- Audience: the narrow user and why they care now.
- Promise: the outcome the app makes easier, calmer, faster, or more delightful.
- Hero feature: the one interaction a demo should revolve around.
- Non-goals: attractive features you are explicitly refusing for v1.
Use the two-week rule
For the first version, assume you need a TestFlight build in two focused weeks. That constraint is useful. It forces the app to become a sharp instrument instead of a small version of a huge product.
- If the app needs accounts, social graphs, complex sync, or moderation to prove value, rescope.
- If the first demo takes more than 15 seconds to understand, rescope.
- If the hero feature cannot be tested with five people in the niche, rescope.
Hand AI a stable target
AI coding tools are strongest when the product target is stable. Give Claude Code or Cursor a brief with screen names, state rules, data shape, and acceptance criteria. Keep taste and product judgment with you; use the tool for implementation momentum.
Draft the v1 brief
- What exact user moment does this app serve?
- What is the hero feature, written as one verb-driven sentence?
- What three features are tempting but forbidden in v1?
- What screens are required for a stranger to feel the value?
- What must be true before you invite the first TestFlight users?
Keep the course path open.
Join the daily digest and get first access when the course opens.