A Shopify development scope of work is a document that names every deliverable, every exclusion, who signs off on each one, and what happens when something breaks after launch. That's it. Most of the arguments we see between Indian D2C brands and their developers aren't about whether the work was done well. They're about a line item nobody wrote down: who was supposed to build the COD eligibility rules, whether the GST invoice PDF was in scope, and what "done" meant for the checkout.
So this post is a scope template built backwards from the disputes. If you're briefing an agency this quarter, the sections below are the ones to fight about now, while it's cheap.
What actually belongs in a Shopify scope of work
Four parts, and the last two are the ones people skip.
- Deliverables. Templates, sections, apps, integrations, migrations, content. Counted. "Product page" is not a deliverable; "one product template plus a variant-heavy template for the apparel range, with size chart drawer and a pincode ETA block" is.
- Exclusions. The list of things a reasonable person might assume are included and aren't. Photography, copywriting, GST registration, courier account setup, Meta pixel debugging on the ad account side, ONDC listing.
- Acceptance criteria. The specific, testable condition under which each deliverable is signed off. Written before the build, not negotiated after.
- Change control. What counts as a change request, how it gets priced, and how long the developer has to quote it.
A scope document without acceptance criteria is a wish list. You'll find out what "responsive" meant to your developer at 11pm the night before a Diwali launch, and by then you have no leverage.
The COD block is three features, not one
"Enable cash on delivery" appears in almost every Indian brief as a single bullet. In the build it turns into at least three separate pieces of work, and if only one was quoted, someone is eating the other two.
- COD availability by pincode. Either from your courier's serviceability API, an uploaded list, or an app. Decide which, and decide who maintains the list when Delhivery changes coverage.
- COD eligibility rules. Order value ceiling, product exclusions (fragile, high-value, perishables under FSSAI), customer blocklists for repeat refusers, and whether a customer with a prior RTO can pay COD again. Each rule is logic someone has to write.
- COD fee or prepaid incentive presentation. Where it shows, whether it's a line item at checkout, and whether it survives a discount code.
On plain Shopify, hiding a payment method conditionally lives in checkout customisations and payment customisation functions, which means a Shopify Function and a deployment pipeline, not a theme edit. On Plus you get more room at checkout. Either way, write in the scope which platform tier the rules are being built for, because a rule that works on Plus may not be buildable the same way below it. If you're weighing that decision, we've written about where the Plus threshold actually bites.
Prepaid incentives: do the arithmetic before you write the line item
Here's the calculation that decides how this feature should be built, and it takes two minutes.
Take a store doing 10,000 orders a month, AOV ₹1,200, 60% COD. That's 6,000 COD orders. Say 22% of those come back as RTO. Forward leg ₹65, reverse leg ₹65, packaging and handling ₹20, so roughly ₹150 lost per RTO. 1,320 RTOs × ₹150 = ₹1,98,000 a month.
Now the incentive. Every COD order you convert to prepaid saves you 0.22 × ₹150 = ₹33 in expected RTO cost. So a prepaid discount above ₹33 per order is losing money on the conversion alone. On a ₹1,200 AOV that's 2.75%. The 5% prepaid discount everyone copies from the brand next door costs ₹60 to save ₹33.
It gets worse. If the incentive is shown store-wide, the 4,000 customers already paying online take it too. 4,000 × ₹60 = ₹2,40,000 of pure margin given away to people who were never going to pay cash.
Which turns into a scope line item: does the prepaid incentive display to all traffic, or only after COD is selected, or only for pincodes above a defined RTO threshold? The third option is real engineering. The first is a discount rule. They are not the same quote, and the brief that says "add prepaid discount" will get priced as the cheap one.
Plug your own RTO rate and shipping costs in. The point is that the number decides the build, so put the number in the document.
GST invoicing is never "Shopify handles it"
Shopify's order confirmation is not a GST tax invoice. It has no GSTIN, no HSN codes, no place-of-supply logic, no CGST/SGST versus IGST split, no invoice serial number series. If your brief says "GST-compliant" and nothing else, you've left the entire thing open.
Write down, explicitly:
- Which app or middleware generates the invoice PDF, and who pays for it
- Whether B2B buyers can enter a GSTIN at checkout and whether it's validated
- HSN code storage: metafield, product tag, or in the invoicing app's own mapping
- Invoice numbering series, and who owns it if you later change apps
- Whether e-way bill generation is in scope or handled by your ops team in the courier panel
- How credit notes for returns and cancellations are produced
Most brands answer that last one with "the CA does it in Tally." Fine. Put it in exclusions and move on. The dispute only happens when nobody says it out loud.
Courier serviceability, address quality and the fields nobody specified
Shiprocket, Delhivery and Blue Dart all expose serviceability differently, and whichever you pick shapes the checkout. A few lines that belong in every Indian requirements document:
- Pincode-to-ETA display on PDP or cart, and the fallback text when the API is slow or down
- Phone number format enforcement, because a 9-digit number becomes a failed delivery three days later
- Address line length limits, since long addresses get truncated on courier labels
- Landmark field, if your ops team wants it, as a custom checkout field
- Who owns the courier API credentials and rate limits
Add a performance line while you're there. "Mobile LCP under 2.0s on a throttled 4G profile for home, collection and product templates" is a testable acceptance criterion. "Fast site" is not. Most of the traffic you're buying on Meta lands on a mid-range Android phone on patchy data, and a third-party pincode widget that blocks rendering will cost you more than the widget is worth. If you want to watch the score after launch rather than trust a one-off report, SwiftStore monitors it continuously; we built it because clients kept asking why a site that was quick in June was slow by October.
Milestones and payment terms that survive a delay
The structure we use on fixed-scope builds, and why each gate exists:
- 20% on signature. Covers discovery, information architecture, the requirements document itself.
- 25% on design sign-off. Wireframes and visual design for the agreed template count, approved in writing. This is the gate that prevents redesigns during development.
- 25% on development complete / staging handover. Everything built, on a password-protected staging store, with test orders placed through Razorpay or PayU in test mode.
- 20% on UAT sign-off. After your team has tested, not after the developer says it's ready.
- 10% at the end of the defect window. Usually 30 days post-launch.
That last 10% matters more than its size. It's the only thing keeping a developer's attention on you in week three after launch, when the next project has started.
Tie every milestone to a client-side dependency clause. If design sign-off needs your product photography and the photography arrives 18 days late, the timeline moves 18 days and the milestone payment still triggers on the developer's delivery, not on your approval. Without that clause, an agency carries your delay on its own cash flow, and the honest ones will price that risk into the quote. Budget context for what these stages usually cost sits in our breakdown of Shopify development pricing in India.
UAT and sign-off: the checklist to run before you pay
Give this to whoever on your team actually knows the operation, not to the person who commissioned the project. Two hours of real testing here saves a fortnight of arguing.
- Place a live prepaid order on a real card and a real UPI handle, ₹10 product, then refund it and confirm the refund lands
- Place a COD order to a serviceable pincode and a non-serviceable one, confirm the second is blocked with a readable message
- Place a COD order above the value ceiling and confirm the method disappears
- Check the GST invoice PDF for GSTIN, HSN, invoice number, and correct CGST/SGST versus IGST for an in-state and an out-of-state address
- Confirm the order syncs to your courier panel with the correct weight and dimensions
- Test discount code stacking against the prepaid incentive, including the case where both apply
- Test on a real budget Android handset over mobile data, not on desktop Chrome with a device emulator
- Abandoned cart and order-confirmation flows firing to WhatsApp and email, with correct merge fields
- 301 redirects from every old URL if this was a migration, checked against a crawl of the old sitemap
- Meta pixel and GA4 purchase events firing once, with correct value and currency
Sign-off should be a named person and a date on a document listing which items passed. "Looks good, go live" in a WhatsApp group is not sign-off, and we've all pretended otherwise at some point.
Stopping scope creep without becoming impossible to work with
Scope creep in Shopify projects is rarely a client trying to get free work. It's usually a founder discovering, in week five, something they genuinely needed and didn't know to ask for. The fix isn't rigidity. It's a change process fast enough that using it feels reasonable.
What works: a single written change log, each request priced within two working days, in hours and rupees, with an explicit note on whether it moves the launch date. Small items under an agreed threshold, say two hours, get absorbed without paperwork. Anything touching checkout, payments or tax logic goes through the full process no matter how small it looks, because those are the changes that break other things.
And a festive clause. From roughly two weeks before your peak sale period to a week after, no structural changes go live. Only bug fixes. Every brand agrees to this in June and asks to break it in October.
Fixed scope or time and materials
Fixed scope works when the requirements document is genuinely finished: template count agreed, app list agreed, integrations named, content ready. It's the right call for a standard D2C build on a good theme, and it's how most of our quotes go out.
It's the wrong call when you're building something you haven't specified, which is most custom app work and most checkout logic on Plus. There, a fixed price either means the developer padded 40% for unknowns or will fight you on every clarification. Retainer or sprint-based billing is more honest. If you don't want a retainer, split the project: fixed price for the storefront, time and materials for the integration layer, with a capped ceiling you both agree to revisit.
The one contract structure to avoid is fixed price with a vague scope and a long list of "and similar items". Nobody wins that one.
A requirements document template you can start from today
You don't need software for this. A shared doc with these headings gets you 90% of the way, and it doubles as the brief you send to developers when you ask for quotes.
- Business context: categories, AOV, monthly orders, COD share, current RTO rate, peak months
- Current stack: platform, payment gateway, courier aggregator, ERP or Tally, email and WhatsApp tools
- Template list with a one-line description of each and any unusual behaviour
- Payments: gateways, UPI, EMI, COD rules as described above
- Tax and invoicing: GST handling, B2B GSTIN capture, invoice generation, credit notes
- Shipping: serviceability source, rate logic, ETA display, free shipping thresholds
- Catalogue: SKU count, variant depth, filter and search requirements, merchandising rules
- Data migration: what comes across, from where, and what's deliberately left behind
- Third-party apps: named, with who pays the subscription
- Acceptance criteria per deliverable
- Exclusions
- Milestones, dates and client-side dependencies
- Post-launch: defect window length, definition of a defect versus a change, support hours and response times
Point 13 needs a sentence of definition or you'll argue about it. A defect is behaviour that contradicts the agreed acceptance criteria. Anything else, including things that work exactly as specified but that you've since decided you dislike, is a change request. Write that down and both sides relax.
How to brief a developer when you don't know the technical answers
You're not expected to specify the implementation. Describe the operation instead, in your own language, with numbers.
Rather than "we need custom COD logic", write: "about 60% of our orders are COD, we lose roughly a fifth of those to refusals, most of them from four or five states, and we want to stop offering cash on delivery to those pincodes above ₹2,000 order value." Any competent developer can turn that into a spec. The reverse, where a merchant guesses at a technical approach and the developer builds it faithfully, is how stores end up with an app subscription that solves a problem nobody had.
Include screenshots of what annoys you on your current site. Include your last three months of order data if you can. Include the deadline and say whether it's real. If you're comparing quotes, the brief should be identical for everyone, or you're comparing prices for different projects. A short note on how to evaluate Shopify developers in India covers the rest of that process.
Start here
Open the scope document you already have and look for the four things: COD rules, GST invoice generation, courier serviceability, and a written definition of the post-launch defect window. If any of them are missing or phrased as a single bullet, that's where your next dispute is coming from. Add them before you sign anything.
If you'd rather have someone else read it first, send it over with a link to your store and we'll mark up the gaps on a free audit. We'd rather argue about scope in a document than in month three.