Push back on any Shopify brief that describes a look or a deadline but not a goal. "Make it like that big brand", "add an app for that", "it's a small change", "we need it live Friday" and "make it pop" all deserve one question back before any code is written: what is this change supposed to do for the store? The answer usually changes the job.
Here's my hot take: a developer who builds exactly what the brief says isn't being helpful. He's being a printer. A good printer, maybe. But nobody hired a printer to grow their store.
Pushing back doesn't mean saying no. It means asking one question so the thing that gets built is the thing that was actually needed.
Why does a vague brief cost more than a clear one?
Because the cost doesn't disappear, it moves. A vague brief gets built on a guess, the guess gets reviewed, and the real requirement shows up in round two or three of feedback. By then there's code to undo as well as code to write. One question at the start is the cheapest change you'll ever make to a project.
"Make it like that big brand's site." What should you ask?
Ask: which part, exactly? Big brands have teams bigger than most stores' whole company, plus custom platforms, photo shoots and budgets that don't fit in a Shopify theme. Usually the client likes one thing: the way the product page feels, the menu, the filters, a clean checkout. Find that one thing and build it properly, instead of a lookalike of the whole site that copies the surface and none of the reasons it works.
"Add an app for that." When is that the wrong answer?
Ask: what does the app need to do, and on which pages? Plenty of apps are worth it. But some requests (a badge on the product page, a simple size note, a small banner) are a few lines of Liquid in the theme. An app for something that small can mean another script loading on every page, another monthly fee, and code left behind in the theme after it's uninstalled. I wrote about which apps are worth keeping and how fewer apps usually beats more.
"It's a small change." How do you know if it is?
Ask: what does it touch? A change can be small on the screen and large underneath. Moving a block on the product page might mean editing a section that five templates share. "Just add a field at checkout" depends on the Shopify plan. "Change the font" can touch every heading style in the theme. Small changes are real and common, but the size comes from what the code touches, not from how it looks in the brief.
"We need it live Friday." What's missing?
Ask: where's the content? Deadlines are fine. Deadlines without product photos, copy, prices or a decision on shipping rates are a plan to launch with lorem ipsum. Ask for the list of what's ready and what isn't, then agree on what Friday actually includes. Usually a smaller launch on time beats a full launch that slips.
"Make it pop." How do you turn that into a task?
Ask: pop for whom, and what should they do next? Pop isn't a CSS property. I checked. What "pop" usually means is "people aren't noticing the thing I care about." That might be the add-to-cart button, a sale, a new collection. Once you know which, the task writes itself: a bigger add-to-cart button above the fold on mobile, a clearer price, a sale banner that doesn't fight the logo.
How I handle it
Every job I take starts with a short call and a written scope. The scope is where the vague lines in a brief get turned into things you can check: what changes, on which pages, what's included and what isn't. It's also why I can quote a fixed price for it. You can't price "make it pop". You can price "bigger add-to-cart button, above the fold, on mobile."
If you have a brief that's half-written, that's fine. Send it as it is through the contact page with your store's URL, and the first call is where we work out the why. If you're not sure what needs changing at all, a Shopify audit is a good place to start.