How to Brief a Developer So You Actually Get What You Want

Years ago, long before Brincore, I watched a company spend the better part of a year building exactly what they asked for. The developers hit every requirement on the list. The thing worked. Nobody used it. The list had been written by people who'd never watched the actual work happen, and by the time anyone noticed, the budget was gone.

I think about that project a lot, because it taught me something that still surprises my clients: most software work doesn't go sideways because the developer was bad. It goes sideways because the brief was. So if you're about to hand someone money to build you an app or a tool, learning how to brief a developer is the highest-leverage thing you can do — more than picking the right developer, more than picking the right technology.

Here's how I'd do it if I were sitting on your side of the table.

Lead with the problem, not the solution

The most common mistake I see is a business owner walking in with a feature list. "I need an app with a dashboard, a login, a calendar view, and push notifications." That's not a brief. That's a guess about the solution dressed up as a requirement.

When you hand a developer a feature list, you've quietly taken on a job you didn't sign up for: system design. And you've taken the developer's most valuable contribution — figuring out the best way to solve your problem — off the table before they've even started.

Tell them the problem instead. "My techs are double-booking jobs because the schedule lives in three places and nobody trusts any of them." Now the developer knows what success looks like. Maybe that's an app. Maybe it's one shared calendar configured correctly. A good developer will tell you. But they can only tell you if you brief the problem, not your theory of the fix.

Describe how the work actually happens

When I ran product at Travelocity, I learned you cannot design anything useful from a conference room. We'd map out a clean, sensible booking flow on a whiteboard, and then we'd watch real people use it and discover they did something completely different — they backed out here, called support there, ignored the button sitting right in front of them. The map in our heads was always tidier than the territory.

Your business is the same. When you brief a developer, describe the real path the work takes, not the org-chart version. Who touches the order first. Where it sits for two days. The spreadsheet nobody admits to maintaining. The one employee who "just knows" how to handle the weird stuff. That messy reality is the thing the software has to absorb, and it's exactly the part most briefs leave out because it's hard to explain. Explain it anyway. It's the most important thing you'll say.

Be specific about what matters and honest about what doesn't

Not every detail carries the same weight, and a good brief makes the priorities clear. There's a world of difference between "it would be nice if" and "this is the whole reason I'm building it." If the thing absolutely must work on a phone in a warehouse with bad signal, say so up front — that one fact changes how the whole thing gets built. If you don't actually care whether the buttons are blue, say that too, so nobody burns a day on it.

I tell clients to sort their wishes into three buckets out loud: must-have, nice-to-have, and someday. The act of doing it usually reveals that half their "requirements" were preferences. That's not a knock on you — it's hard to see from the inside. But every hour a developer spends on a someday item is an hour stolen from a must-have, and you're the only one who knows which is which.

Say what "done" looks like

Before anyone writes a line of code, you and the developer should be able to finish this sentence the same way: "We'll know this worked when ______." Maybe it's "the schedule stops getting double-booked." Maybe it's "we stop paying for the old system." Whatever it is, write it down.

This is the step almost everyone skips, and it's the one that prevents the worst outcome in software — building the wrong thing competently. When I co-founded CityFront and we built the first AI agent for 311 service requests, the brief that mattered wasn't "build an AI app." It was "a resident should be able to report a pothole in their own language and have it land in the city's system without a human retyping it." That sentence told us what done looked like, and everything we built either served it or got cut.

The part you don't have to do

Here's the relief: you do not need to learn to speak technical to brief a developer well. You don't need to know what an API is or whether it should be built in React. If a developer makes you feel like you need that vocabulary to be taken seriously, that's a problem with the developer, not with you.

Your job is to be the world's leading expert on your own business and to describe it honestly — the problem, the real workflow, the priorities, and what done looks like. The developer's job is to translate that into technology. When both people stay in their lane, you get what you wanted. When the lines blur — when you start designing the solution or they start guessing at your business — you get that year-long project nobody uses.

If you've got a build coming up and you want a second set of eyes on the brief before you hand it to anyone, [book a free conversation](https://outlook.office.com/owa/calendar/Brincore@brincore.com/bookings/). No pitch. I've written and received enough of these to help you get yours right — and sometimes the most useful thing I can tell you is that the project you're briefing is smaller than you think.