How to Prepare a Project Brief Before You Start a Project
The clearer your brief, the faster we can scope accurately. Here's what to include before your first conversation with us.
A good project brief isn't a formal document — it's a clear statement of the problem you're solving, who it affects, and what success looks like. The more of that you can put in writing before we talk, the faster we can give you an accurate scope instead of a guess.
Start with the problem, not the solution. Instead of "we need a customer portal," describe what's actually breaking down today: manual handoffs, duplicate data entry, customers calling in for information that should be self-service. The symptoms tell us more than a feature list ever could.
Include who's involved and what they'd need on day one — internal teams, customers, or both. If you already have systems in place (a CRM, an ERP, a legacy database), name them; how a new build connects to what already exists is often the most important scoping question.
Finally, be honest about constraints: budget range, timeline, and any hard deadlines tied to a business event. We'd rather scope around a real constraint than propose something that gets renegotiated later.
Related guides
Let's talk about your project
If this raised a question specific to your situation, we're glad to walk through it — no pitch, just a straight answer.