Write a Project Brief That Prevents Scope Creep

The project starts with enthusiasm and a vague understanding of what 'done' looks like.

3 steps 1 tool 30-60 minutes per brief, plus hours of avoided scope disputes

The Problem

The project starts with enthusiasm and a vague understanding of what 'done' looks like. Three weeks later, the client adds a feature that was 'obviously included,' you thought the timeline started after the design phase, and nobody wrote down what was out of scope. The brief that should have prevented all of this never got written because writing a good brief is tedious and you just wanted to start building.

How Chapeta Handles This

Describe the project in whatever level of detail you have — even rough notes from a discovery call. Chapeta turns it into a structured brief with scope, deliverables, timeline, assumptions, out-of-scope items, and open questions. The brief becomes the reference document that prevents misalignment later.

How to Write a Project Brief

3 steps to get it done

  1. 1

    Dump what you know

    Tell Chapeta about the project: what the client wants, what you are building, rough timeline, budget if relevant, and any decisions already made. Raw notes from a call work fine. Do not worry about structure — that is the AI's job.

  2. 2

    Get the structured brief

    Chapeta organizes your input into standard brief sections: objective, scope, deliverables, timeline, assumptions, dependencies, out-of-scope items, and open questions. It fills in gaps where common-sense assumptions apply and flags questions you should resolve before starting.

  3. 3

    Review and share

    Read through the brief, adjust anything that does not match reality, and send it to the client or stakeholder for sign-off. The explicit out-of-scope section is the one that saves you later.

Example

You type

Write a project brief from these notes. Client: SaaS company, ~50 employees. Project: redesign their onboarding flow. Budget: $15K. Timeline: they want it done in 6 weeks. I'm doing UX research, wireframes, and high-fidelity mockups. They handle implementation. We had a call where they mentioned wanting to 'fix the whole user experience' but I think they mean onboarding specifically.

Chapeta returns
## Project Brief: Onboarding Redesign — [Client Name]

### Objective
Redesign the onboarding flow to reduce drop-off between signup and first value. Focus on the experience from account creation through first successful use of the core product.

### Scope
- UX research: 5-8 user interviews + analysis of existing onboarding analytics
- Wireframes: 3-5 key screens in the onboarding flow, 2 rounds of revision
- High-fidelity mockups: Final designs in Figma, ready for developer handoff
- Handoff documentation: annotated specs for the implementation team

### Deliverables
1. Research summary with key findings and recommendations (Week 2)
2. Wireframes v1 for review (Week 3)
3. Wireframes v2 incorporating feedback (Week 4)
4. High-fidelity mockups + handoff specs (Week 6)

### Timeline
| Phase | Duration | Dates |
|-------|----------|-------|
| Research | 2 weeks | Weeks 1-2 |
| Wireframes | 2 weeks | Weeks 3-4 |
| High-fidelity design | 2 weeks | Weeks 5-6 |

### Budget
$15,000 total. Payment schedule to be confirmed (recommended: 50% upfront, 50% on delivery).

### Assumptions
- Client provides access to existing analytics and 5-8 users for interviews
- Feedback turnaround on wireframes is within 3 business days
- The client's engineering team handles implementation after handoff
- 'Onboarding' means signup through first core action, not the full user experience

### Explicitly Out of Scope
- Full UX audit beyond the onboarding flow
- Implementation, QA, or post-launch iteration
- Marketing site or landing page design
- Mobile app design (desktop/web only unless otherwise agreed)

### Open Questions
- Does 'onboarding' include the email welcome sequence or just the in-app experience?
- Are there existing brand guidelines or a design system to follow?
- Who is the primary decision-maker for design approvals?
- The client mentioned wanting to 'fix the whole user experience' — confirm this is limited to onboarding before starting.

Without Chapeta

Open a blank document. Try to remember everything from the discovery call. Write scope bullets. Realize you forgot to define what is NOT included. Add a timeline that does not account for feedback rounds. Send it to the client. Get a revision request that includes three things you thought were out of scope. Wish you had been more specific upfront.

Time saved 30-60 minutes per brief, plus hours of avoided scope disputes

FAQ

Try the Write a Project Brief workflow in Chapeta