Five things an Australian agency reselling Shopify builds has to keep in its own hands: the client relationship, the Shopify Partner organisation the store lives under, the IP chain, the scope document, and whatever goes into client-facing copy that the ACCC could take an interest in. Everything else — theme code, Liquid, app configuration, data migration, QA, ongoing tickets — can sit with an offshore build partner without anyone noticing or caring. White label Shopify development for agencies goes wrong in predictable places, and almost none of them are code quality.
We build under other agencies' names, mostly for design studios and full-service shops in Sydney, Melbourne and Brisbane. What follows is the stuff we see handled badly on the first project, usually by good agencies who've just never had to think about it.
What white label Shopify development for agencies actually covers
You sell the build. Someone else writes the code. Your client never learns the subcontractor's name, never gets an email from them, never sees their logo on anything. That's the whole arrangement.
Can agencies resell Shopify development services? Yes. Shopify's Partner Program has no problem with an agency subcontracting delivery, and no rule requires you to disclose who wrote the Liquid. What does matter is who holds the Partner account, who gets collaborator access, and who is recorded against the store when it goes live. Those are administrative facts with commercial consequences, and they're set on day one whether you think about them or not.
The other thing worth being clear about internally: white label is not the same as staff augmentation. If you want a developer in your Slack, in your standups, taking direction from your producer, that's a different contract with different economics. Plenty of agencies want that instead and should say so. Dedicated developers billed monthly are cheaper per hour than project work and worse at fixed deadlines. Pick deliberately.
Store ownership and the Partner organisation handover
This is the one that costs money later.
When a development store is created and then transferred to a client, the Partner account that made the transfer is the one Shopify records against that store. If your subcontractor spins up the dev store from their own Partner dashboard because it was faster, the relationship attaches to them. Not catastrophic, but it means merchant support pathways, Plus organisation visibility and any partner-side tooling sit with a company your client has never heard of. Undoing it after launch is a support ticket and a conversation you'd rather not have.
So: create the development store in your Partner organisation. Give the build team a collaborator account with the permissions they need and nothing else — themes, products, apps, orders if they're touching fulfilment logic, never billing or staff management. At handover, transfer store ownership to the client's email, make the client the account owner, then revoke collaborator access for anyone who doesn't need it in the maintenance phase.
Shopify Plus adds a wrinkle. The organisation admin holds the real keys — user management, store creation, payment settings across stores. If your client is on Plus, the org owner should be the client from the start, with your agency as an org-level user and the build team scoped to a single store. We've seen a build partner left with org admin on a three-store Plus setup eighteen months after the project ended. Nobody noticed until an audit.
One awkward case worth naming: if the client already has a store and you're rebuilding on a duplicate theme, there's no dev store transfer at all, and the attribution question is moot. Different handover entirely. Make sure your process has both paths, because a checklist written for greenfield builds quietly fails on replatforming projects.
NDA, IP and attribution terms that actually hold
Three documents, in this order.
A mutual NDA between your agency and the build partner, signed before scoping, covering the client's identity as well as their data. If the subcontractor can't name the client in a pitch, say so in the agreement rather than assuming it.
An IP assignment clause that works as a chain. The build partner assigns everything they produce to you on payment; you assign it to the client on payment. If either link is missing, you're promising your client ownership of something you don't own. Carve out the obvious exceptions honestly: licensed apps, third-party libraries, the partner's internal tooling and any pre-existing component library. A client who gets a build containing a proprietary filter module they can't modify after you part ways is a complaint waiting to happen, so either license it to them perpetually or don't use it.
An attribution clause. No logo on the partner's site, no case study, no mention in the Shopify Partner Directory, no LinkedIn post about the launch. We hold this rule without exception and would expect any partner you hire to do the same. If you want to release a joint case study later, that's a separate written permission from the end client, not an assumption.
Add a non-solicit that runs both ways and is short enough to actually be enforceable. Twelve months, direct contact only. Anything longer reads as paranoia and gets negotiated out anyway.
Pricing white label Shopify work without eroding your margin
The headline margin is never the real margin. Here's the arithmetic we'd run before quoting.
Say you quote a client $26,000 for a Shopify build: custom theme from their designs, product data migration, Afterpay and Zip configured, Australia Post and Sendle rates at checkout, a subscription app, and a two-week support tail. Landed delivery cost from your build partner, fixed price, is $8,500. Gross margin looks like $17,500, or 67%. Lovely.
Now subtract your own time. Discovery, client calls, design QA, three rounds of feedback wrangling, launch day: call it 55 hours of senior time at an internal cost of $95 an hour, so $5,225. Two changes the client swore were in scope but weren't, which you absorb rather than fight: another $1,400 to the partner. A week of post-launch fixes nobody budgeted: $900. Real margin, $9,975 — about 38%. Still a good project. Not 67%.
Which leads to the practical rules on how to price white label Shopify work. Buy fixed price, sell fixed price, and never let the two scopes differ by a single line. If you buy hours and sell hours you're a labour broker with a 20% spread and no defence when the client asks what you did. Price on outcome and hold a contingency of 10–15% of the build cost inside your own number, because there is always one integration that behaves differently in production — usually a shipping rate rule for WA and regional postcodes, or an ERP that returns stock counts in a format nobody documented.
Currency: fix the AUD rate for the project duration in the contract, or price the whole thing in AUD and let the partner carry the exchange risk. A build quoted in USD and delivered over five months can move enough to eat your contingency.
GST: your invoice to the Australian client carries 10% on the full sell price. Your invoice from an Indian supplier, exporting services, shouldn't carry Indian GST. Whether anything is reportable on your side depends on how you're registered and what the services are for, so put it to your accountant once and then stop thinking about it. If you want a sense of the underlying rate card before you build a price list, our cost breakdown for Shopify development in India shows how projects are usually structured.
How design agencies should split the work
Most of the Australian agencies we work under are design-led. They have strong art direction, a Figma file with real craft in it, and nobody who wants to think about metafield definitions at 11pm.
The split that works: the design agency owns art direction, UX decisions, copy and the client relationship. The build partner owns information architecture in the platform sense — metaobject structure, section schema, how a content editor will actually update the homepage in eighteen months — plus performance budgets and QA.
Where it breaks is the handoff file. A Figma board with no defined states for out-of-stock variants, no mobile breakpoint for the collection filter, no empty-cart design and no error state on the Afterpay instalment display will produce a build that comes back with guesses in it. Then the revision rounds get spent on things that were never designed. We ask for those states upfront and we still get them about half the time. Budget accordingly, or pay for a design QA pass in the middle of the build rather than at the end.
The AU–India clock, described honestly
The overnight cycle is real, but it isn't the 24-hour factory some offshore pitches imply.
Bengaluru works 9:30am to 6:30pm IST. In AEST that's 2:00pm to 11:00pm. So an Australian agency gets roughly three to four hours of live overlap at the end of its own day — enough for a daily call, a screen share, a decision — and then the build carries on for another five hours after your office has closed. Feedback given at 4pm Sydney time gets worked on that same evening. It's waiting when you open your laptop.
What it isn't: a same-day answer to a question asked at 9am. Your morning is their night. If your producer sends a blocker at 9:15am AEDT, nothing moves until roughly 3pm. Teams that plan around this — writing up blockers at the end of the Australian day rather than the start — get a genuine extra cycle per day out of the arrangement. Teams that don't spend six months mildly annoyed.
The one hard rule: agree on when the partner is reachable outside those hours. Launch nights, Click Frenzy week and the Boxing Day sale all happen at times that are awkward from India. Put on-call windows in the contract, with a rate, rather than relying on goodwill at 2am.
Claims in client copy are your liability, not the developer's
A build partner will happily implement whatever text lands in the brief. "Carbon neutral shipping." "100% Australian made." "Delivered in 2 business days, Australia-wide." None of those are development decisions, and all of them are the kind of thing the ACCC has been actively pursuing where the evidence behind a claim is thin.
Keep sign-off on any environmental, provenance or delivery claim inside your own agency, with the client's written confirmation on file. This matters specifically on the pages a developer touches without thinking: shipping policy, product badges, the checkout upsell, the "why us" block a theme ships with as placeholder. Delivery promises are the sneaky one, because a two-day estimate that's fine for metro Sydney is not fine for Kalgoorlie, and the estimate usually lives in a theme setting that somebody filled in to make the page look finished.
The same applies to Afterpay and Zip messaging. Instalment copy has its own rules and the providers publish what's acceptable. Read it once, hand your partner the approved strings, and don't let anyone write their own.
White label support and maintenance after launch
The build is the small part of the relationship. Maintenance is where reselling either becomes a business or becomes a headache.
Sell a retainer with a stated monthly hour block, a response time, and a named freeze window. For Australian merchants that freeze runs from roughly the first week of November through to mid-January, because Click Frenzy, Black Friday, Christmas and Boxing Day arrive in one continuous run and nobody should be deploying a new cart drawer on 20 December. A second, smaller freeze in the last fortnight of June covers EOFY sales. Write both into the retainer and your client will thank you for it later.
Tickets should come to you and go out to the partner, always. The moment a client emails a developer directly, your margin and your control both start leaking. Use a shared board if you like, but the client's view of it is yours.
Performance is the part of maintenance that quietly decays, because every app a merchant installs adds script weight and nobody attributes the slowdown to any single one. Build a quarterly check into the retainer rather than waiting for the client to notice the site feels heavy. If you want it monitored continuously without adding a line item to your own cost base, SwiftStore scans PageSpeed, fixes what it can automatically and tracks the score over time; we also do deeper speed work as a fixed-scope project when a store has drifted past the point an app can fix.
Choosing a white label Shopify partner for agencies
Questions we'd ask if the positions were reversed:
- Who owns the code in the contract, and can you show me the assignment clause before we start scoping?
- What happens to my client's store access on the day the project ends — describe the revocation steps.
- What's your policy on contacting or naming the end client? Get it in writing.
- Have you shipped with Australian shipping rate logic before, including parcel-weight rules for regional and WA delivery?
- Who answers on launch night, and what do you charge for out-of-hours cover?
- What's your fixed-price change process? "We'll be reasonable" is not a process.
Ask for a small paid pilot first. A single section build, a speed pass, a data migration — something with a clear definition of done, priced under a couple of thousand dollars, that tells you how the partner communicates when something goes slightly wrong. It always tells you more than a portfolio does.
If you're weighing this up for a specific project, send us the scope and we'll come back with a fixed price and the handover checklist we'd use, so you can see the process before you commit to anything. Our Australian work page covers how we structure engagements, and a free audit of an existing store is a reasonable way to test us on someone else's mess before you hand over one of your own.