How to brief a developer without speaking their language

A good brief is the difference between a quote you trust and a quote that's really a guess. But most people freeze up here, because they assume a brief has to be technical. It doesn't. The best briefs are written in plain English by the person who understands the problem best, you.

Describe behaviour, not technology

You don't need to say "use a Postgres database with a REST API." You need to say what should happen: "a customer can save their favourite items and see them next time they log in." That single sentence tells an engineer they need accounts, storage, and a way to keep people logged in, without you naming any of it.

Focus on who does what, and what they see afterwards. Behaviour is something you're an expert in. Technology is the developer's job.

Name the edges

Where projects go over budget is almost always the edges, the "oh, and also" moments discovered halfway through. You can prevent most of them by thinking through a few questions up front:

• Who's allowed to do what? (Customers, staff, admins.)
• What happens when something goes wrong? (A payment fails, a booking clashes.)
• What has to connect to the outside world? (Payments, maps, email, calendars.)

You don't need the answers to be technical. You just need to raise them, so they're scoped instead of discovered.

Bring a plan, not just a paragraph

A paragraph describing your idea is a fine start. An itemized plan, broken into modules, grouped into phases, with each part explained, is what actually gets you an accurate quote. It shows the engineer you've thought it through, and it gives them a shared document to price against line by line.

That's the whole point of a build plan: it lets a non-technical founder and a senior engineer look at the exact same thing and mean the exact same thing by it.