A project brief should answer three questions before it talks about technology.
**What is broken today?** Describe the process, not the tool. Who does what today, where does it slow down, and what does it cost you?
**What does better look like?** Give us a measurable outcome — time saved, errors reduced, revenue recovered.
**What must not break?** Existing integrations, data you cannot lose, compliance constraints.
Everything else — stack, architecture, timelines — follows from those answers. When those three are clear, the technical conversation becomes short.
