I read every brief that comes through the contact form myself. The ones that turn into good projects tend to share a handful of traits — and none of them are about polish. A rough brief with the right substance beats a beautiful one that dances around the problem.
Here's what helps me give you a useful answer quickly.
The problem, in plain words
Not the solution you've already picked — the problem underneath it. "We need an MCP server" is a solution. "Our customers want their AI assistants to look up orders, and we don't want to hand an agent write access to production" is a problem. The second one tells me far more.
A constraint or two
Budgets, deadlines, a tech stack you're committed to, a launch you can't move. Constraints aren't bad news; they're what makes an estimate real instead of a guess.
"We have a fixed budget of X" is one of the most helpful sentences a brief can contain. It lets me scope to what's possible instead of guessing.
What success looks like
How will you know this worked? A number is ideal — faster pages, more conversions, hours saved — but even a clear qualitative goal helps me aim the work at the outcome instead of the feature list.
What you've already tried
If you've taken a run at this and it didn't work, tell me. Knowing what failed saves us both from repeating it, and it usually points straight at the real constraint.
What I'll send back
Usually a couple of clarifying questions, an honest read on whether I'm the right fit, and either a rough shape for the work or a time to talk it through. If it's not something I should take on, I'll say so and point you somewhere better.
That's it. You don't need a polished document — you need to tell me the truth about the problem. Send a brief and we'll go from there.