How to Write a Shopify Project Brief That Gets Accurate Quotes

If you have received quotes ranging from £4,000 to £20,000 for what you thought was one project, the cause is almost never that some developers are greedy. It is that your brief left nine important things unstated, and each developer filled the gaps differently.

A good brief is the cheapest thing you can do to improve a project. It gets you comparable quotes, it removes most scope disputes before they exist, and — counterintuitively — it usually lowers your prices, because ambiguity is priced as risk and clarity removes the buffer.

This is a structure you can work through, plus the specific gaps that cause the most damage.

Why vagueness costs you money

Worth understanding the mechanism, because it explains why effort here pays.

When a developer reads an unclear brief, they have three options. They can quote the optimistic interpretation and raise change requests later, which is how projects become adversarial. They can quote the pessimistic interpretation with a large buffer, which is how you get an expensive quote for a simple job. Or they can ask you twenty questions, which is the right answer and which many will not do because it takes unpaid hours.

The first two are both bad for you. The third is what you want, and writing a proper brief gets you there without requiring the developer to be unusually conscientious.

There is a second effect. A brief that demonstrates you have thought carefully attracts better suppliers, because good developers prefer clients who are organised. A vague brief attracts whoever is least busy.

The nine gaps that cause the most damage

If you address nothing else, address these.

1. Your app and plugin inventory. Every app or plugin currently running, and what each one does for the business. On a migration this is the single largest source of hidden scope, because each needs a replacement, a rebuild, or a decision to drop. List them all, including the ones you rarely think about.

2. Your integrations. Every system your store exchanges data with — accounting, ERP, 3PL, POS, email, reviews, loyalty, anything internal. For each, say which direction the data flows and roughly how often. Integration work is often the largest line in a quote and it is frequently omitted from briefs entirely.

3. Your catalogue complexity, specifically. Not just the product count. How many options does your most complicated product have? Do you have configurable or personalised items? Bundles? Products with many attributes? This determines whether Shopify’s structure fits without workarounds, and it is a common source of mid-project surprises.

4. Custom functionality and business rules. Anything your current store does that is not standard: tiered pricing, customer-group pricing, quantity breaks, conditional shipping logic, approval workflows, custom calculators. Write down the actual rules, not just the feature name. “We have wholesale pricing” and “we have eleven customer groups with different quantity break structures plus contract pricing for forty accounts” are very different projects.

5. Your content volume. Number of content pages, number of blog posts, and whether they need migrating or rebuilding. Hundreds of pages is real work and it is almost never in a brief.

6. Your current traffic and SEO position. Roughly how much organic traffic you get, which pages produce it, and whether you have significant search visibility. This tells the developer how much care the redirect and preservation work needs — and if you omit it, some will assume none is required.

7. Who supplies content, images, and product data. You, or them. This can swing a quote substantially and it is one of the most common post-signing disputes.

8. Your decision-making process. Who approves things, how many people are involved, and how quickly you can turn things around. Experienced developers price approval chains, because review cycles drive timelines.

9. Your actual constraint. Budget range, deadline, or both. Clients withhold budget fearing they will be priced to it. The practical effect is receiving proposals you cannot afford and wasting a round for everybody. A range lets a developer tell you what is achievable within it.

A brief structure you can fill in

Work through these sections. Length is not the point — completeness is.

1. About the business. What you sell, to whom, roughly what scale, and what is changing. Two or three paragraphs. This gives a developer the context to spot when your requirements work against your objectives.

2. What you want to achieve. Not the features — the outcome. “Our mobile conversion is half our desktop rate and we think the store is why.” “We are spending too much maintaining WooCommerce.” “We want to launch subscriptions and cannot on our current platform.” This is the section that lets someone challenge your brief usefully.

3. Current situation. Platform, theme, roughly how old the store is, who built it, whether it has been modified heavily, and what you know about its condition. If a previous developer left undocumented custom work, say so — it changes the estimate and hiding it does not help you.

4. Scope: what you want done. As specifically as you can. Break into must-have and nice-to-have, which lets a developer phase the work and gives you a lever if quotes come back high.

5. The inventory sections. Apps, integrations, custom functionality with actual rules, catalogue complexity, content volume. Use the nine gaps above as a checklist.

6. Design. Keeping your current design, adapting a premium theme, or a custom build. If design matters to your brand, say so and expect it to cost accordingly. Include reference sites you like and what you like about them.

7. What you will supply. Content, images, copy, product data, and by when.

8. Technical and commercial constraints. Systems you must keep, compliance requirements, markets and currencies, anything non-negotiable.

9. Timeline and any fixed dates, with the reason. “Before our trade show in March” is more useful than “as soon as possible”, because it tells a developer what can flex.

10. Budget range.

11. How you will decide, and by when. Courteous and it tells suppliers whether to prioritise your proposal.

12. Questions you want answered in the proposal. Ask everyone the same things so you can compare — process, staffing, testing, handover, and post-launch support.

What to include for a migration specifically

Migrations need more, because the risk is concentrated in things briefs usually omit.

A full URL inventory, or at least a count by type. Products, collections, blog posts, content pages. If you can run a crawl, attach it.

Your organic traffic by landing page for the last twelve months, or the top fifty pages at minimum. This is the single most useful attachment you can provide.

Whether you have subscriptions, and how many active subscribers. This changes the project fundamentally.

Where your reviews live and how many you have.

Your plugin list with business function for each.

Any custom fields or product data beyond standard Shopify fields.

Explicitly: who owns the redirect map and post-launch SEO monitoring. Asking this in the brief forces an answer, and the answers will differ enough to be informative.

A worked example: the brief that halved the quotes

A specialist tea retailer first approached developers with a one-page brief: migrate from WooCommerce to Shopify, around 400 products, keep the look similar. Quotes came back at roughly £6,000, £13,000, and £22,000.

Unable to compare them meaningfully, they rewrote the brief. It took most of a day.

The new version listed their fourteen plugins with what each did, noted that two handled wholesale pricing rules they wrote out in full, listed their accounting and 3PL integrations, stated that they had 380 blog posts and 22 content pages, attached a spreadsheet of their top 100 pages by organic traffic, flagged that their reviews lived in a specific plugin with 2,400 reviews, confirmed they would supply all content and imagery, named one decision-maker, and gave a budget range.

They sent it to the same three developers plus two more.

The new quotes ranged from £11,500 to £16,000 — a much tighter band. The £6,000 quote became £11,500 once its author understood the wholesale rules and the redirect scope. The £22,000 quote came down to £15,000, because much of its buffer had been risk pricing for unknowns that were now known.

They hired at £13,000 and the project finished close to budget with two small change requests.

The day spent on the brief did three things: it made the quotes comparable, it removed roughly £7,000 of risk buffer from the high quote, and it prevented the £6,000 engagement that would have ended badly for everyone.

Common mistakes

Describing features instead of outcomes. “We want a mega menu” invites a mega menu. “Customers cannot find products in our deep catalogue” invites a conversation about whether navigation, search, or filtering is the answer. The second gets you better advice.

Hiding the state of your store. If your theme has been modified by four developers and nobody documented anything, saying so gets you an accurate estimate. Concealing it gets you an optimistic one followed by a difficult conversation.

Omitting the boring systems. Accounting integrations and 3PL connections are unglamorous and they are frequently the largest cost in the project.

Listing every nice-to-have as a requirement. This inflates quotes and obscures priorities. Separate must-have from nice-to-have explicitly.

No budget range. Covered above. It costs you a round of proposals and some goodwill.

Sending it to too many suppliers. Five is plenty. Fifteen means nobody invests effort in the response.

Asking for a fixed price on a vague brief. You will get a padded number or a change-request project. Either specify properly or accept a discovery phase.

Not saying what you will supply. The single most common post-signing dispute.

How to write out business rules properly

This deserves its own section because it is where briefs fail most expensively, and because writing rules out is a skill nobody teaches.

The problem is that feature names hide complexity. “We have wholesale pricing” could mean a single discount percentage for tagged customers, or it could mean eleven customer groups with different quantity break structures plus negotiated contract rates for forty accounts plus a credit approval workflow. Those are different projects by an order of magnitude, and both get described the same way.

Write rules as if explaining to a new employee. Not the feature name — the actual logic, in order, with the edge cases.

A weak description: “Trade customers get discounted pricing with quantity breaks.”

A useful description: “We have three trade tiers assigned manually when an account is approved. Tier 1 gets 20% off list, Tier 2 gets 30%, Tier 3 gets 40%. On top of that, quantity breaks apply per product line: 10+ units gets a further 5%, 25+ gets a further 10%. Quantity breaks are calculated per product line, not per order total. Around 30 accounts have individually negotiated rates that override the tier discount but still receive quantity breaks. Trade customers do not see retail prices anywhere on the site and cannot use promotional discount codes. Trade orders over £2,000 require approval before they can be placed.”

The second version takes ten minutes to write and eliminates an entire category of mid-project discovery. It also lets a developer tell you immediately whether you need Shopify Plus, which is a material fact about your budget.

Include the exceptions, because exceptions are where the cost is. Legacy customers on old pricing, one-off arrangements made by sales years ago, products excluded from discounts, regions with different rules. These exist in every established business and they exist in nobody’s documentation.

Say what customers must not see. Visibility rules are as much work as pricing rules and are almost always omitted.

Note what currently happens manually. If somebody in your office adjusts prices in a spreadsheet each month, say so. That is either work to automate or work to keep, and it needs a decision.

Do the same for shipping rules, tax handling, and any approval workflow. Same principle: actual logic, in order, with exceptions.

Before you send it

A short pass that improves most briefs considerably.

Give it to someone in your business who was not involved in writing it and ask what is unclear. Their questions are the questions developers will ask.

Check every feature has a reason attached. If you cannot say why a requirement exists, it may not need to, and flagging your own uncertainty invites useful challenge.

Separate must-have from nice-to-have honestly. If everything is essential, you have no lever when quotes come back high and no way to phase the work.

Attach rather than describe where you can. A crawl export, a spreadsheet of your top pages, screenshots of your current product page, a list of apps copied from your admin. Attachments are faster to produce than prose and more accurate.

State explicitly what is out of scope. Naming what you are not asking for prevents both padding and misunderstanding.

Invite challenge in writing. A line saying you would welcome views on anything in the brief that looks wrong gives permission to disagree, and some developers need it.

Keep a version. When someone asks in month three whether something was in the original brief, you will want the answer.

The bottom line

A day spent on your brief tightens your quote range, removes risk buffers, prevents most scope disputes, and attracts better suppliers. It is the highest-return work available to you in the whole hiring process.

Address the nine gaps above all: apps, integrations, catalogue complexity, custom business rules written out properly, content volume, your SEO position, who supplies content, your decision process, and your budget range.

Then describe outcomes rather than features, so the developers you approach can tell you when your brief works against what you are trying to achieve. That conversation is what you are actually buying — and a good brief is what makes it possible to have.

Frequently asked questions

What should a Shopify project brief include?

Context about your business and what you are trying to achieve, your current situation including the honest state of your store, the scope split into must-have and nice-to-have, and then the inventory sections that most briefs omit: every app with its business function, every system you integrate with, your catalogue complexity including your most complicated product, any custom pricing or business rules written out as actual rules, your content and blog volume, and your current organic traffic position. Then say who supplies content, who decides, what your deadline is driven by, and your budget range.

Why do I get such different quotes for the same Shopify project?

Because the brief left gaps and each developer filled them differently. One quoted for moving your products while another quoted for rebuilding the wholesale pricing logic and the redirect map you did not mention. Faced with ambiguity, a developer either quotes optimistically and raises change requests later, or quotes pessimistically with a large risk buffer, and both outcomes are bad for you. Specifying the nine commonly missing items — particularly apps, integrations, custom business rules, and content volume — routinely collapses a wide quote range into a narrow one.

Should I include my budget in a Shopify project brief?

Yes, as a range. The usual fear is being priced to your wallet, and the practical cost of withholding it is receiving proposals you cannot afford and wasting a round for everyone. A stated range lets a developer tell you what is achievable within it, propose phasing if your scope exceeds it, or decline early if it is unrealistic — all of which are more useful than a proposal you reject on price. If you are concerned about anchoring, give a range with a note that you are looking for the best approach within it rather than a number to hit.

How detailed should my brief be for a Shopify migration?

More detailed than for a new build, because migration risk sits in exactly the things briefs usually leave out. Include a URL inventory or at least counts by type, your top pages by organic traffic over the last year, your full plugin list with what each does, where your reviews live and how many there are, any custom product fields, and whether you have subscriptions and how many subscribers. Then ask explicitly who owns the redirect map and post-launch SEO monitoring. That last question alone will differentiate your shortlist significantly.

Will a better brief make my project cheaper?

Often, and by more than people expect. Ambiguity gets priced as risk, so a developer facing an unclear brief either builds in a buffer or quotes low and recovers through change requests. A complete brief removes the buffer, and in practice we see high quotes come down substantially once the unknowns are resolved. It also prevents the cheap-quote outcome where a project is priced against a scope you never intended, launches incomplete, and costs considerably more to put right. A day of writing is the best-value work in the process.

Do I need to write a brief if I am hiring a freelancer for a small job?

Not a full one, but a few lines beat a verbal conversation even for small work. State what you want changed, on which pages or templates, what the outcome should look like, whether you are supplying any content or images, and any deadline. Attach a screenshot with annotations if the change is visual — that removes more ambiguity than any amount of description. The reason to bother on small jobs is that small jobs are where scope creep is least visible: a series of undocumented tweaks becomes a dispute about what was agreed, and neither party has a record.

How many developers should I send my brief to?

Around five is the practical maximum. Fewer than three leaves you without comparison; more than five or six means nobody invests real effort in their response, because the odds no longer justify the unpaid work of scoping properly. Send to a shortlist you have already filtered by looking at their live work, tell them how many others you are approaching and when you will decide, and ask everyone the same set of questions so the proposals are comparable. Approaching fifteen suppliers produces fifteen thin responses rather than more choice.