A lot of the emails we get start with an apology. The brief isn't ready. There's no spec. Someone has a folder of screenshots and a date they pulled off a slide, and they don't want to waste our time until it looks cleaner.

Send it anyway. We'd rather read the ugly version than wait for a deck that papers over the parts you haven't decided yet.

OZP is a small studio in Seattle. We don't run a workshop week to look like a bigger shop, and we don't hand you off to a discovery department that won't be on the build. The first few days are the same people reading what you sent, asking the obvious questions, and writing down what we think the job actually is. That's the start. The “real brief” usually shows up after those questions, and it's better because of them.

What we need to know

Not a vision document. Not a full spec. Answers to these, even if they're half-formed:

• Who uses this on a Tuesday at 4pm, and what they're trying to finish before they leave.
• What exists today — a spreadsheet, a shared inbox, a vendor nobody likes. All of that counts.
• Who can say no. If that person is “looped in later,” the estimate is for a project that doesn't have an owner yet.
• What done looks like in one sentence you'd send to whoever is paying for this.
• What happens if we're late. A missed launch, a missed grant, and a missed season are different jobs.

If you can't name who can say no, we can still talk. We just shouldn't pretend the date is real until that person is in the conversation.

When a tidy brief is worse

The briefs we distrust aren't messy. They're complete in the wrong way: a feature list copied from a competitor, a Figma file with no owner, “we need an app” with no job attached, AI named before a user is, a timeline that exists because the quarter ends.

We've taken messy briefs and been fine. The harder ones are the tidy rebuilds where nobody has decided what this replaces. Payroll still runs on the old system. Nobody wants to be the person who turns it off. That's normal — but then the work isn't “rip and replace by Q3.” It's a cutover, a fallback, and someone on your side who still understands what's there. If that person doesn't exist, we need them before we need a build estimate.

What we do with whatever you send

We read it. We try to talk to someone who will live in the thing, not only the person who hired us. Then we write back a short document: the problem as we understand it, the constraints, what we are not doing in this phase, a rough shape of the system, and a number.

That document is the estimate. If the problem changes, the number changes. We'd rather be awkward about that in week one than surprised in month three.

You don't have to wait until it looks like a brief. The angry email, the spreadsheet with the broken formulas, the screenshot of the screen people actually use — that's usually enough to start.