Your Shopify Client Changed the Scope Mid-Project. What Should You Do Next?

You’re eight days into a Shopify build. The theme is customised, the product template is done, the collection filters work, and you’re about to start migrating 400 SKUs. Then the founder sends a Loom:

Small thing. Our top sellers should be available as a monthly subscription too. Same products, just with a subscribe option. Should be quick, right?

On Shopify, almost nothing is one thing. A subscribe toggle on a product page reaches into the app stack, the cart, the checkout, the customer account, the email flows and the merchant’s payment setup. Here’s how to handle the ask without eating the cost, and without turning into the agency that says no to everything.

Why small Shopify asks are rarely small

Merchants judge effort by the storefront, because the storefront is all they see. The platform decides how much work actually sits behind each request.

• Apps bring their own surface area. A subscriptions app means selling plan groups, a widget that has to be styled into your theme rather than dropped on top of it, and an app block that needs testing on every template it appears on.
• Checkout is the least flexible part of the store. On standard plans it isn’t yours to redesign. On Plus, customising it means checkout UI extensions and Functions, which is real development, not theme work.
• Recurring orders change the back end. Inventory forecasting, fulfilment routing, discount logic, tax handling and the merchant’s gateway all behave differently for a subscription than for a one off sale.
• Every add on multiplies QA. Cart drawer, dynamic checkout buttons, Shop Pay, gift cards, discount codes, Klaviyo flows. One new purchase path re-tests all of them.
• App fees are the merchant’s, forever. Monthly platform fees and revenue share belong in the cost of the request even though none of it lands on your invoice.

The failure mode isn’t that the work is hard. It’s that you quoted a theme build and you’re now being asked to quietly deliver a commerce redesign.

Sort the request: in scope, out of scope, or a defect

Compare it to the signed scope and run three checks.

1. Was this purchase path in the brief? “Custom Dawn based theme, 400 products migrated, Klaviyo connected” doesn’t contain subscriptions, bundles, wholesale pricing or B2B.
2. Does it add a new app, a new integration or a new order type? Any of the three is out of scope by default. Those are the three things that generate ongoing maintenance you never priced.
3. Is the current behaviour broken, or just not what they now want? Variant swatches failing on mobile are your problem. Variant swatches that should now be colour grouped across products are a change.

Keep absorbing the true trivia. Copy tweaks, a section reorder, a colour change in the theme settings. Charging for fifteen minute jobs buys you a reputation for nickel and diming and saves you nothing.

Document it before you quote it

Write down, in one place:

• The request in the merchant’s words. “Subscribe option on our top sellers”, not your interpretation of it.
• Your reading of what that means concretely. Which products, which intervals, whether customers can pause or swap, what happens to existing customers.
• The surfaces it touches. Product template, cart, checkout, customer accounts, email flows, the 3PL.
• What’s excluded. “Migrating existing customers to subscriptions is not included. A customer facing subscription portal beyond the app default is not included.”

Writing the exclusions is the highest leverage ten minutes in this whole process. It’s also where you find out the request is bigger than the merchant thinks, before you’ve promised anything.

Quote the money and the launch date together

Money. Your build hours, plus the QA hours the new purchase path forces, plus the merchant’s recurring costs: app subscription, revenue share, any plan upgrade the feature requires. Show the recurring costs separately and label them clearly. A merchant who learns about 1% revenue share after launch will treat it as something you hid.

Date. Translate hours into the calendar, because merchants plan around campaigns, not sprints. “This moves launch from 3 September to 12 September” is a business decision they can actually make. Say it plainly when the date is the real cost. If BFCM traffic starts and the store isn’t live, the feature cost far more than the invoice says.

Offering a phase two option here isn’t weakness, it’s good consulting. Launch on the 3rd as scoped, add subscriptions in October when there’s time to test them properly. Merchants take that deal more often than you expect, and you keep both the date and the revenue.

Get the yes in writing, from the decision maker

In a Shopify project the person messaging you is often the marketing manager or the ops lead, not the person who owns the P&L. Approval needs to come from whoever can commit budget, and it needs to sit against the specific numbers.

• One document holding scope, price, recurring cost and new date.
• A timestamped yes or no, stored where neither side can rewrite it.
• An easy decline. “Not now” is a completely acceptable answer and you want it fast, before you’ve reserved development time.
• An expiry date, so an unanswered request doesn’t quietly hold your schedule hostage.

Build after approval, not during it

The temptation on Shopify is real, because installing the app takes four minutes and it feels like progress. Resist it. An installed app on the merchant’s store is a fact on the ground that argues you already agreed. If you need certainty before quoting, sell a small paid spike: two hours of app evaluation and technical discovery, approved on its own, with the estimate as the deliverable.

Keep the record until the last invoice clears

Shopify projects generate a steady drip of small asks. A bundle here, a Markets region there, a Flow automation, one more Klaviyo integration. Individually forgettable. Together, the difference between a 30% margin and a 5% one.

A per project list of every approved change, with price, date impact and approver, does three jobs. It justifies the final invoice, it shows the merchant how much extra value they actually bought, and it gives you the data to scope the next store properly.

What it looks like in practice

Making this survive a busy week

No Shopify agency fails at this because they disagree with it. They fail because on the day the request lands, writing a mini proposal is the least urgent thing on the list. By the time the invoice goes out, the thread has scrolled away and nobody can say who approved what.

StayScoped exists to make that step take two minutes instead of thirty. Write the change, add the cost and the new date, send one link. The merchant approves or declines without creating an account, and the answer is logged against the project with a timestamp. When the final invoice goes out, the receipts are already sitting next to it.