How to brief a Shopify developer (and get a useful quote)

When three developers quote the same Shopify job at very different prices, they are rarely pricing the same job. Each filled the gaps in the brief with their own assumptions. A better brief doesn’t need to be long or technical. It needs to remove the guesses that make quotes unreliable.

Shopify’s own advice to merchants hiring a Partner says the same: define your budget, timeline and expected outcomes in detail so the Partner can give an accurate quote.

What a developer needs to price the work

A developer estimating a job is asking three questions: how much there is to build, what could make it harder than it looks, and how they will know they are finished. The first depends on the outcome you describe. The second depends on your store: its theme, apps and integrations. The third depends on whether you have said what “done” means. Most vague quotes trace back to one of the three.

The seven parts of a useful brief

1. The store. Its URL, your Shopify plan, the theme and version you run, and the apps and integrations that touch the area in question. Plan matters: only Shopify Plus stores can use custom apps that contain Shopify Functions, for example, which changes how checkout rules are built.
2. The outcome, not the solution. “B2B customers must not check out below 12 units” lets the developer choose the right tool. “Add a JavaScript popup to the cart” locks in one answer, sometimes the wrong one.
3. What exists and what was tried. Current apps, old customizations, anything that stopped working, and fixes that didn’t hold. This is where the hidden risk sits.
4. Constraints. A real deadline and why it exists, markets and languages, B2B or wholesale rules, and anything that must not change.
5. How you will judge it done. Two or three concrete checks: “a 12-unit order passes, an 11-unit order is blocked with a message at checkout”.
6. A budget range. A ceiling or a range lets a developer propose what fits, instead of pricing the most complete version and losing you, or the cheapest and disappointing you.
7. People and decisions. Who approves the work, who supplies content and images, and how quickly questions get answered.

A weak brief and a useful one

An illustrative example, not a real client:

The useful version is not longer because it is technical. It is longer because it answers the questions the developer would otherwise have to ask, or guess.

Screenshots help more than adjectives. A screenshot of the page with the problem marked, or a short screen recording of the steps that go wrong, removes a round of questions. If the problem only happens on one device, browser or market, say which.

A brief you can copy

Fill in what you know and leave the rest blank; a blank line tells the developer what to ask about.

Store: https://…  (Shopify plan: …)
Theme: name and version; edited by others before? yes / no
Apps and systems involved: …

What should happen:
  …  (the outcome, in one or two sentences)
Who it is for: all customers / B2B / one market / …

What exists today:
  …  (current setup, what stopped working, what was tried)

Constraints:
  Deadline: …  because …
  Must not change: …

Done when:
  1. …
  2. …

Budget range: …
Decisions by: name, role; content supplied by: …

Questions a good developer will ask back

A reply full of questions is a good sign, not a delay. Expect some of these, and treat a quote that asks none of them with care:

• Which Shopify plan are you on, and does the solution need to work on a lower plan later?
• Which apps touch this area today, and can any of them be removed?
• Is there existing custom code, and who wrote it?
• How will the change be tested before it goes live, and who signs it off?
• What should happen to orders, customers or content that already exist?

Sharing access safely

Don’t put passwords in a brief, and don’t share your own login. Shopify has a mechanism for this: collaborator accounts. A Partner asks for access with a request code you give them; you approve the request and assign roles with only the permissions the work needs. Collaborators don’t count toward your store’s user limit, two-step authentication is required for them, and you can generate a new request code at any time so old codes stop working.

A first estimate rarely needs access. A URL, screenshots and a description are usually enough; access can wait until the work is agreed.

Comparing the quotes you get back

• Assumptions. A good quote says what it assumed. If two quotes assume different things, you are comparing different jobs.
• Exclusions. Content entry, app subscriptions, design, testing on other devices: what is not included matters as much as what is.
• How changes are handled. Fixed price, time-based, or a mix, and what happens when the scope changes mid-way.
• Where the work happens. Changes to a theme should be built and reviewed on an unpublished copy, not the live theme.
• Handover. Who owns the code, where it is stored, and what documentation you receive.
• Billing. A Partner found through Shopify’s Partner Directory bills you directly; those charges don’t appear on your Shopify bill.

Choosing who to hire is a separate question. The brief is the same whether it goes to a freelancer, an agency or your own developer, and a good one makes their answers comparable.

How Lintel’s brief works

Lintel’s project brief asks for the same essentials in one short form: your name and work email, your website or store URL, what you need (custom app, Shopify Functions, theme engineering, integrations and more, or “not sure”), and the problem, including the apps, Scripts or systems involved. It asks you not to include passwords or store access. The founder reviews every brief, usually within 24 hours; scope and pricing are discussed next, and work starts only once both are agreed.