Case study: a Shopify store empire built on 30 stealth accounts
Case study: a Shopify store empire built on 30 stealth accounts
this case study follows an operator I’ve known since 2023, who I’ll call Marcus. he’s based in Kuala Lumpur and runs a network of e-commerce stores focused on print-on-demand and light dropshipping across multiple niches. when I first met him in a private Telegram group for Southeast Asian operators, he had three stores and was already experimenting with how to scale horizontally without a single point of failure. eighteen months later, he had thirty.
the premise was straightforward: rather than betting everything on one Shopify store and one ad account, Marcus wanted to segment by niche, by traffic source, and by risk. if Meta banned one ad account, only that store’s traffic went dark. if a supplier ran dry in one vertical, other stores were untouched. the isolation was the strategy, not just a compliance workaround.
the headline result after 18 months: 30 active stores, a total infrastructure overhead around $1,500 per month, and a network that survived two Stripe account suspensions and one full Shopify store ban without material disruption. this is not a story about striking it rich, it’s a story about building a system that didn’t collapse when things went wrong.
the setup
Marcus ran everything through AdsPower on their Team plan, which at the time of his initial build ran around $50 per month for up to 100 browser profiles. each store got its own browser profile with a unique canvas fingerprint, WebGL hash, and user-agent string. he combined that with rotating residential proxies from Smartproxy, spending roughly $80-100 per month on a 10GB residential package that he topped up as needed. datacenter IPs were useless here. Shopify’s fraud detection flagged them almost immediately during account creation, so he paid the premium for residential.
for emails, he registered 30 domains through Namecheap at roughly $10-12 per domain per year and pointed them to Zoho Mail’s free tier for individual aliases. this kept email cost close to zero beyond the domain registrations, roughly $300 upfront for the full batch. each store had its own domain email, its own support inbox, its own brand identity.
the payment side was where the real cost and complexity sat. Marcus had four registered LLCs, two in Malaysia and two in the UK via a £12/month incorporation service. each entity held up to eight Shopify stores and a corresponding Stripe account. he explicitly did not use a single person’s identity across all accounts. each LLC had a real director and real business registration. this distinction matters and I’ll come back to it. total entity maintenance ran around $150-200 per month between registered address fees and annual filing services.
the full stack, monthly:
| item | monthly cost |
|---|---|
| 30x Shopify Basic ($39/store) | $1,170 |
| AdsPower Team plan | $50 |
| Smartproxy residential | $95 |
| Zoho Mail (free tier) + domain renewals amortised | $25 |
| LLC maintenance (4 entities) | $180 |
| Misc tooling (Slack, Notion, Airtable) | $60 |
| total | ~$1,580 |
the stores themselves covered three niches: pet accessories, fitness gear, and seasonal home decor. within each niche, Marcus had five to twelve stores pointed at different sub-segments, price points, or traffic demographics. a few stores ran organic TikTok, most ran Meta paid, and two experimented with Google Shopping.
what worked
fingerprint isolation held up. in 18 months, Marcus had zero cross-contamination bans where Shopify or Meta identified two accounts as related purely through browser fingerprint or IP. the AdsPower profiles stayed cleanly separated. he ran Shopify store creation through the profiles, kept customer service on the same profiles, and never mixed sessions across stores on the same machine without switching profiles. this sounds obvious but the discipline required to maintain it across a team of three VAs is real. he used Loom walkthroughs and a written SOP before anyone touched the setup. for a deeper look at how antidetect browser profiles work in practice, antidetectreview.org’s blog covers the mechanics of fingerprint spoofing better than I can here.
entity separation was the real protection. when one of Marcus’s UK LLCs had its Stripe account suspended in month 11, eight stores lost payment processing overnight. that’s a bad day. but the other 22 stores kept running. he had the suspended entity’s stores moved to a new payment processor (Shopify Payments under a different entity) within four days. because the entities were genuinely separate, with different directors and different banking relationships, the suspension didn’t cascade. compare this to operators who run 30 stores under one individual’s identity, where a single Stripe ban pulls everything down simultaneously.
niche segmentation reduced ad account blast radius. Meta bans ad accounts. this is a known, recurring cost of doing business in paid social. Marcus structured his campaigns so that each Meta ad account mapped to one niche cluster, not one store. a ban on the fitness ad account hurt, but the pet and home decor accounts kept spending. his VAs each managed one niche cluster end to end, which also made them more effective since they understood the creative and audience.
supplier pre-negotiation at scale. by month six, Marcus had enough combined volume across his pet stores to negotiate direct pricing with two Chinese suppliers via a sourcing agent. the pricing benefit flowed to all pet stores simultaneously, improving margins across the cluster without any individual store being large enough to command it alone. this is one of the underrated advantages of horizontal scaling.
template stores for rapid deployment. he built three master Shopify themes, one per niche, and saved them as private themes. launching a new store took one afternoon: clone the theme, update branding, populate products via DSers, configure the new AdsPower profile, done. the operational overhead of adding store number 28 was not meaningfully higher than adding store number 8.
what broke
Stripe clustering on banking behaviour, not browser fingerprint. two entity suspensions in 18 months. in both cases, the pattern Stripe flagged wasn’t a browser fingerprint match, it was transaction velocity patterns that looked similar across entities to their risk models. specifically, both suspended entities were in the fitness niche and had similar average order values, similar refund rates, and their payouts were both going to Malaysian accounts. Marcus suspects the risk model flagged the combination of refund rate plus payout geography rather than anything technically identifying. the fix was to use separate acquiring banks in separate jurisdictions for future entities and to watch refund rates obsessively. Stripe’s services agreement is worth reading carefully before scaling, particularly the sections on high-risk categories and account termination rights. it’s not a document designed to protect you.
supplier inventory sync became a nightmare at scale. with 30 stores and multiple suppliers, Marcus was manually checking stock levels and pausing product listings whenever a supplier ran out. by month nine this was consuming four to six hours of VA time weekly. the fix was imperfect: he standardised on DSers for supplier management and set inventory buffers in each store so products auto-hid when stock dropped below a threshold. this worked about 80% of the time. the remaining 20%, usually holiday season stock spikes, still required manual intervention.
customer support volume didn’t scale with store count cleanly. thirty stores meant thirty inboxes, thirty sets of tracking queries, and thirty potential dispute pipelines. Marcus had one VA per niche cluster handling support, but the Shopify notification routing across accounts required each VA to be logged into multiple Shopify accounts simultaneously. they ended up routing all support email to a single Gorgias workspace with store tags, which cost an additional $60 per month but made the support workload manageable. the lesson here is that support infrastructure needs to be consolidated early, before the volume hits.
the numbers
I’m not going to invent a revenue figure. what I can share is the unit economics Marcus described at month 18.
average order value across the network sat between $45 and $65 depending on niche, with fitness running higher and pet accessories running lower. customer acquisition cost on Meta averaged around $10-14 for proven creatives, rising to $18-22 during testing phases. gross margins before ad spend ran 35-45% on dropshipped products, closer to 55-60% on print-on-demand lines. these are not exceptional numbers. they’re typical for the category, which is the point: the model worked not because the unit economics were unusual, but because the infrastructure meant more tests could run in parallel with less correlation between failures.
the $1,580 monthly overhead, spread across 30 stores, works out to roughly $53 per store per month in fixed infrastructure cost. for stores doing even modest volume that’s noise. for new stores in testing, it’s a real cost to carry, and Marcus maintained discipline about cutting stores that hadn’t reached breakeven within 90 days of launch.
Shopify’s own terms of service don’t prohibit owning multiple stores, but they do prohibit using the platform to circumvent bans, run counterfeit goods, or violate their acceptable use policy. Marcus’s stores were all selling legitimate products with genuine supplier relationships. the multi-entity structure was a business risk management decision, not an attempt to deceive the platform. that distinction matters legally and practically. this is not legal advice; consult a qualified attorney for advice specific to your structure.
lessons
isolation only works if every layer is isolated. browser fingerprints, IPs, emails, payment processors, business entities. leave one layer shared and you’ve created a point of failure that can pull the whole thing down. Marcus’s browser isolation was excellent from day one. his banking isolation was weaker and that’s where he got hit.
start with three stores, not thirty. the operational discipline required to maintain 30 isolated environments is not trivial. Marcus built to 30 gradually, adding five to eight stores at a time as his SOP tightened and his VA team grew. operators who try to launch twenty stores simultaneously typically create a mess of cross-contaminated sessions, shared IPs, and inconsistent supplier setups that undermines the whole premise.
residential proxies are not optional. if you’re doing multi-account Shopify work seriously, you need residential IP allocation at account creation and during ongoing store operation. Shopify’s fraud signals pick up datacenter ranges quickly. the cost difference between datacenter and residential proxies has closed significantly since 2022. there’s no good reason to cut corners here. see our guide to residential proxy selection for current pricing comparisons.
the real risk is payment processors, not Shopify. Shopify banning one store is a nuisance. a payment processor suspending an entity and holding funds is a genuine operational crisis. plan for it in advance: have a second processor ready to activate, maintain good refund rates, and understand what your processor’s acceptable use categories actually cover. Marcus now keeps Shopify Payments and a secondary processor active on every entity, with monthly volume split to maintain relationships with both.
automate supplier sync before you need it. the inventory problem at scale is real and predictable. DSers, AutoDS, or a direct API integration with your suppliers should be in place before store fifteen, not after store twenty-five.
team SOPs are infrastructure. the antidetect setup is only as good as the discipline of the people operating it. Marcus’s Loom walkthrough library and written SOPs were as important as his AdsPower configuration. a VA who doesn’t understand why they can’t log into store A’s profile while store B is open in another window will eventually create exactly the cross-contamination the whole system was built to prevent. treat the human operating procedures as a core part of the technical stack. our multi-account operations guide covers SOP templates worth adapting.
would I do it again
Marcus’s answer, when I asked him directly in February 2026: yes, but not the same way. he’d start with entity structure first, get four LLCs and four separate banking relationships in place before launching a single store, rather than retrofitting the legal structure around an existing account cluster. the retrofitting was the most painful part, migrating stores between entities mid-operation while maintaining continuity. he’d also invest in Gorgias from store one, not store twenty-two.
the 30-store model isn’t for everyone. the overhead is real, the operational discipline is demanding, and the ceiling on any individual store is lower because you’re spreading resources across a wider surface. what the model provides is resilience. when Meta has a platform event, when a niche goes cold, when a processor gets trigger-happy with suspensions, the blast radius is contained. for operators whose primary fear is catastrophic single-point-of-failure risk, the horizontal model has genuine merit. for operators who want to go deep on one brand, this is the wrong architecture entirely.
the tools Marcus used are real and available. the approach is replicable. whether it pencils for you depends entirely on your volume, your niche, and your operational capacity. if you’re already running multiple accounts and want to understand the browser fingerprinting side in more detail, the comparison guides at antidetectreview.org are worth an afternoon of reading before you commit to a platform. and the full index of operator guides is always at multiaccountops.com/blog/.
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.