The quality of a project brief determines the quality of the quote you get back — and the quality of the project that follows. Developers who receive detailed briefs can scope accurately, start faster, and encounter fewer surprises mid-build. Developers who receive vague briefs quote conservatively, ask lots of questions, or make assumptions that turn into scope disputes.
Here's what a useful Shopify project brief includes.
What you're building and why
Start with context. What is the store, who buys from it, and what's the goal of the project? "We sell premium pet accessories to UK dog owners. We want to rebuild the store because our current theme is slow and doesn't showcase our photography well" tells a developer much more than "we need a new Shopify theme".
The goal matters because it shapes every decision. A rebuild driven by performance has different priorities than a rebuild driven by conversion rate, which has different priorities than a rebrand. Say what you're trying to achieve, not just what you want built.
Where you are now
Include a link to your current store if you have one. Describe the current setup: what theme are you using, what apps are installed, what are the main pain points with the current store?
If you're on a different platform (WooCommerce, Wix, BigCommerce), say so. If you're launching from scratch, say that too. Migrations, rebuilds, and new builds have completely different scopes even if the end result looks similar.
The full scope of what you need
This is where most briefs fall short. Be specific about:
Pages and templates. How many unique page templates do you need? Homepage, collection, product, cart, and checkout are standard. Beyond that: landing pages, blog, about, contact, custom account page, brand story page? List them.
Key features and functionality. Is there anything non-standard? Subscriptions, a product configurator, size guide, loyalty programme, custom filtering, B2B wholesale pricing, multi-currency, multi-language? Every feature mentioned in the brief is scoped upfront; every feature that appears during the build is a change order.
Integrations. What third-party tools need to connect? Klaviyo, a reviews app, a returns portal, Google Analytics, Meta Pixel, a loyalty programme? Each integration requires setup and testing — list them.
Content. Do you have Figma designs, or does design need to be included? Do you have product photography and copy ready, or does the developer need to work with placeholder content first? Be honest — "we're still shooting products" adds weeks to the timeline if it's not flagged upfront.
Reference sites and design direction
Include three to five stores or websites you like and explain specifically what you like about each one. "I like the typography on this site", "I want the product page layout to feel like this one", "this brand's mobile experience is what I'm aiming for". This is infinitely more useful than colour preferences or abstract adjectives like "premium" or "modern".
If you have Figma files, brand guidelines, or existing design assets, mention them. If you're starting fresh with no visual direction, that's also useful to know — it means the brief should include design as a deliverable.
Timeline and budget
State your ideal launch date and whether it's a hard deadline. "We need to be live before Black Friday" shapes the project plan entirely. "We'd like to launch in Q3 but it's flexible" is a different project.
On budget: it helps to give a range even if you're unsure. "We have $5,000–$8,000 for this" allows a developer to scope accordingly and tell you what's achievable within that. "We don't have a budget in mind" usually produces a quote that either overshoots what you expected or undershoots what you actually want.
You don't have to commit to a number — but if you have a ceiling, saying so saves everyone time.
Who's involved and how decisions get made
How many people need to approve design decisions? Is there a founder, a CMO, and an external branding agency all with opinions? Or is it one person with authority to sign off at each stage? Approval chains significantly affect timeline. One decision-maker with clear authority moves fast. A committee moves slowly.
Also: who is the day-to-day contact for the developer during the project? Make sure it's someone who can respond quickly to questions and review work within a day or two.
What a complete brief looks like
Put together, a solid brief includes: what you're building and why, your current setup and pain points, a complete list of pages and templates, all the features and integrations you need, your content readiness, reference sites with specific notes, your timeline and whether it's fixed, your budget range, and how decisions get made.
This isn't a long document — it can be a structured email or a two-page Google Doc. What matters is that every section is answered honestly, including the parts where you're not sure yet.
A developer who receives this brief can quote accurately, start quickly, and build without constant back-and-forth. One who receives "we need a new Shopify store, please quote" is going to ask all these questions before they can do either. Save that time by answering them upfront.
Ready to send a brief? Use the contact form and I'll respond with a quote or a short list of clarifying questions within 24 hours.
