Why I don't take blank-slate briefs
Why Dream Creative does its best work on products already in motion, where the constraints and rough edges are visible.
At some point I started turning down a certain kind of project. Not because the clients were difficult, or the budget was wrong, or the timeline was unrealistic. Because the project didn’t exist yet.
“We have an idea for an app.” “We’re thinking about building something in this space.” “We’d love to explore what this could look like.” These are real sentences from real conversations about real projects - and they’re describing something I’m not the right person for.
It took me a while to understand why. The honest version is this: I’m not good at ideation from scratch. I’m good at looking at what exists and making it considerably better.
There’s a type of creative practitioner who does their best work at the beginning of a project - sitting with a blank page, generating options, exploring territory. They’re excellent at the question “what could this be?” They thrive on ambiguity. The ideal engagement for them starts with no constraints.
I’m not that person. The constraint is the work for me. The existing design that almost works. The prototype that has the right idea but the wrong execution. The half-built tool where the core loop is there but the edges are rough. These are the contexts where I can see clearly what needs to happen next.
This isn’t a limitation I’m reluctant to admit. It’s a description of where the value is.
Here’s the practical difference between a blank-slate brief and a project-in-motion.
With a blank-slate brief, the first six to eight weeks are spent establishing what the thing is. What problem does it solve? Who uses it? What’s the simplest version? This is genuinely useful work - but it’s discovery and strategy work, not design and build work. The deliverables are documents, not products.
I can do that work. I choose not to take briefs for it because it’s not where I add disproportionate value. The ratio of time spent to outcome quality isn’t in my favour when the problem is still being defined.
With a project in motion, the situation is different. The problem has been defined - imperfectly, probably, but defined. Something has been built. Someone has tried to use it. There are real constraints: existing data, existing users, existing expectations. And within those constraints, there are a specific set of things that are wrong or missing, visible to anyone who looks at the product with fresh eyes.
That’s where I work well.
The other reason is more about the quality of the outcome than the quality of the process.
Products built from scratch by external practitioners - even good ones - often miss something essential that the founding team has but can’t fully articulate. The instinct for how the product should feel. The institutional knowledge of why certain decisions were made. The understanding of the user that comes from having watched real people struggle with the product for months.
When I come in on a product that’s already moving, that knowledge exists. My job is to bring the external view - the fresh eyes, the craft, the experience with this class of problem - and apply it to something the team already understands deeply. That collaboration produces better work than either party would produce alone.
When I come in at the start of a blank-slate project, that knowledge doesn’t exist yet. We’re all guessing, including the founders. The product that comes out of that process is often coherent but wrong in ways that only become apparent once real users touch it. The iteration happens later, after more time and money have been spent on the initial version.
I’d rather come in after the initial iteration, when the wrongness is visible.
None of this means I won’t talk to someone early in a project. If you have a prototype that’s been through a few months of user testing, even a rough one, I want to see it. If you have a clear problem statement, a target user, and a view on the constraints, that’s often enough to start a useful conversation.
What I don’t do well is “we’d love to get your ideas on what this could be.” Because I’ll spend the whole conversation looking at the blank space where a prototype should be, imagining what it would tell me if it existed.
Send me something that exists. Even if it’s broken. Especially if it’s broken.