We Turned Down a Project Because the Brief Got It Wrong

The Brief Was Fourteen Pages Long

It had wireframes. A feature list. A tech stack preference. A timeline with phases. The founder had clearly spent real time on it.

We read the whole thing twice. Then we wrote back and asked one question: what problem are your users trying to solve right now that they cannot solve?

The answer we got was: "They need a better dashboard."

That is not a problem. That is a guess dressed up as a requirement.

We turned the project down. Not because the founder was difficult or the budget was wrong. We turned it down because building what that brief described would have produced something expensive, technically sound, and probably useless.

What the Brief Actually Said

Here is a paraphrase of the core ask. The founder ran a B2B logistics platform. Their brief requested a mobile app with AI-powered shipment recommendations, a real-time tracking dashboard, and a client portal with role-based access. They wanted it built in sixteen weeks.

Every line described a feature. Not one line described a user behavior, a failure point, or a business outcome they were trying to move.

When we pressed further, we found out that their current clients rarely logged into the existing platform. Retention was dropping. Support tickets were high. The founder believed the interface was the problem, so the solution in their mind was a better interface.

Maybe they were right. But we did not know that. They did not know that. Nobody had actually talked to the users who stopped logging in.

Building a new product on top of an undiagnosed problem is how you spend $80,000 to confirm the hypothesis was wrong.

Why This Is a Red Flag, Not a Preference

We are not precious about this. Founders come in with strong opinions on solutions all the time and sometimes they are correct. Vision matters. Having a product point of view is not the problem.

The problem is when the solution is the only thing in the brief.

When a brief skips the problem entirely, a few things tend to happen during the build. Scope grows because nobody can say no to a feature without a north star to measure it against. Timelines stretch because decisions get relitigated at every milestone. And the product ships to silence because the people who were supposed to use it were never part of the thinking.

We have seen this pattern enough times to recognize it in the first call. It is not unique to early-stage founders either. We have seen it from operators with ten years of experience who have just gotten too close to their own idea.

In May 2026, this problem has a new layer. A significant portion of the briefs coming in right now include AI as a feature requirement without any grounding in what the AI is supposed to do for a real user. "We need AI recommendations" is the new "we need a mobile app." It sounds strategic. It often is not. And building AI features onto a product whose core problem is undefined is not innovation, it is technical debt with a better pitch deck.

What a Good Brief Actually Looks Like

A brief that works answers four things before it describes a single feature.

Who is struggling and with what, specifically. Not "our users want better tools." Something like: small fleet operators running five to twelve vehicles spend forty minutes per day manually reconciling trip logs because the current export format does not match their accounting software.

What they are doing right now instead. Are they using a spreadsheet? A competitor? Nothing? This tells you where the real friction is and it tells you what the bar for success actually is.

What success looks like in a number. Not "improve the experience." Something like: reduce that reconciliation time to under five minutes, or cut support tickets about data exports by 60 percent in ninety days.

What you have already tried and why it did not work. This is the most skipped part of every brief we receive. If you tried to fix this before and it failed, that is not a weakness in your brief. That is the most valuable signal you have.

Once those four things are clear, the feature conversation becomes fast and grounded. We can tell you in thirty minutes whether a mobile app is the right surface or whether a simple API integration solves the same problem for a tenth of the cost.

What We Told the Founder

We did not just decline and move on. We sent back a one-page brief template and suggested they spend two weeks talking to ten users who had churned or gone quiet in the last ninety days.

We told them to come back after that.

They did not, at least not yet. That is fine. The right project is one where the founder and the team are solving the same problem. When the brief only describes a solution, we are not solving the same problem. We are just executing someone else's guess.

The One Thing to Do Before You Hire a Dev Team

Before you write a feature list, write one paragraph that describes the specific moment a specific user gets stuck today. What are they doing? What do they wish would happen? What do they do instead?

If you cannot write that paragraph, you are not ready to build. You are ready to do research.

That is not a criticism. That is the most useful place to start.