We extract structure from your brief automatically (no hand-coding required), but the brief has to actually say these things or we can't build a real app from it. Our guard rejects briefs that don't meet the thresholds below so you don't waste a build slot.
// need ≥ 3
Distinct roles
The different kinds of people who interact with the system. Not just "user" + "admin" — give them job-shaped names with what each does.
"Membership Coordinator", "Pro Shop Manager", "Director of Tennis", "Board Member"
// need ≥ 5
Things the system tracks
The nouns your business cares about — records, documents, events. Each should be concrete enough to put in a database table.
"Member Application", "Court Booking", "Dues Invoice", "Tournament Draw", "Audit Event"
// need ≥ 2
End-to-end workflows
Multi-step processes named after the WORK being done — not the path type. "Quote a new event", not "Happy path". Include hand-offs and at least one exception.
"New application → coordinator review → board approval → welcome packet emailed"
// need ≥ 3
Named screens
The pages users actually interact with — a list view, a detail view, and at least one task-specific surface. Name them by what the user sees, not by route.
"Reservation calendar", "Suite detail panel", "Daily check-in roster"
// need ≥ 4
Done-criteria
What a reviewer would check to confirm the app works. One sentence each, focused on observable behaviour rather than UI details.
"A member can book a court 7 days ahead; admin overrides go to audit log; finance sees only paid bookings"
// already have a long PDF / SRD / RFP from your team? Just upload it as-is — the extractor handles 5K–30K chars of structured prose comfortably. Aim for 2–4 pages of plain English over 15+ pages of formal spec.