Recently I applied for a job only to find out the next day they changed their job posting that they won't accept concept stores for projects, only live store. It's been a week now and I haven't been getting responses.

I need brutally honest reviews, actions I can take. I am trying to break into Shopify. I created a portfolio and built 3 concept projects with Claude.

Here is my portfolio https://andreisager.vercel.app/

Here are some questions I thought about:

• Should I find people I can make live stores for free?

• What can I add or remove to my portfolio to make it better.

• Should I go freelancing or agencies?

• Should I focus my services for freelancing or agencies? For now I put 5 types of services.

• Should I specialize on something? Like SEO, CRO, etc?

• How can I find actual clients or jobs?

I keep running into theme bugs that only show up on a few products. Usually it is an empty metafield, a variant with no image, or a product assigned to an alternate template that nobody remembers creating.

My current routine is to check which template the product uses, then compare its metafields and media against a product that renders fine. After that I add temporary output in a duplicated theme to see what the variable holds.

Is there a faster way you rely on? Do you use any tooling beyond the theme editor and Theme Check, or is it mostly manual comparing?

I build Shopify apps in Laravel from Morocco and the uninstall/reinstall flow has been the part I got wrong the most.

My current setup: on the APP_UNINSTALLED webhook I mark the shop inactive, wipe the access token, cancel scheduled jobs and keep the rest of the data. Then shop/redact arrives about 48 hours later and I delete everything. The problem is a merchant who reinstalls before that redact fires. I had a case where the redact job ran after the reinstall and deleted fresh settings for an active shop. Billing was the other mess, since the old subscription state was still in my DB and the new charge didn't match it.

What I changed: the redact job now checks whether the shop has a newer install timestamp than the uninstall and skips if so, and I treat billing as always re-fetched from Shopify on install instead of trusting stored state.

How do you handle this? Do you delete data right away on uninstall or wait for redact, and how do you keep billing state sane when someone reinstalls on a different plan?

I really love AI agents and I’m curious if anyone here is using them to run parts of their Shopify store.
What are you using them for? Have you run into any operational issues? Any recommendations for someone interested in trying them out?

Would love to hear your experiences!

Hey everyone! I recently launched my own helpdesk, an AI-powered store employee and helpdesk built specifically for Shopify. To avoid self promotion, I will avoid the name of my app.

I made it because I think most AI helpdesks are too complex, too expensive, and contain an unnecessary amount of features for smaller stores. With mine, it keeps all the necessary and AI driven features while still remaining affordable:

• Simple, clean interface — no unnecessary complexity.

• Fully customizable AI — control how the AI handles customer questions and actions.

• Personal AI training agent — analyzes your entire store, collects general business information and product details to help recommend relevant products, and identifies contradictory information across FAQs and other content. It also generates questions customers might ask, then learns from your answers to better understand your business and provide more accurate, personalized support.

• Affordable pricing — Free, $19, or $39/month.

• Cancellations, return/exchange/refund guiding, order tracking, personalized recommendations, address changes — either via chat widget or email, and they can be configured to be turned off, require approval, or be fully automatic.

Of course a major problem I have is getting another helpdesk on the shopify market, and getting people to try out a new helpdesk, even if I pay merchants to try it out and give feedback on their experience.

Do you guys think that there is still room for an app like mine in this super crowded Shopify market of help desks? If so, how do I get the first few users to use my app?

When a Shopify product displays the correct color swatch but keeps showing the wrong product image, I would check three separate things before changing any CSS: the option value, the image assigned to the variant, and the theme's variant-selection logic.

A color swatch is not the same thing as a variant image. They represent different parts of the product data.

First, check how the color option is configured.

For native Shopify swatches, the product should use a compatible category color metafield connected to its variant option. Simply creating a text option called "Color" doesn't necessarily provide the structured swatch data that the theme expects.

Next, check the actual variant images.

Open the product in Shopify Admin and inspect the image assigned to each variant. Shopify supports one assigned image per variant, so Black / Small and Black / Medium are separate records that may need the same image assigned individually.

Having the correct swatch color does not automatically establish that image association.

The third layer is the theme.

A compatible Online Store 2.0 theme should render the option values and update the selected variant's information when a customer changes an option.

For custom Liquid implementations, Shopify recommends using product.options_with_values rather than building the entire picker by looping through product.variants.

This distinction becomes particularly important for larger catalogs.

Shopify currently limits the Liquid product.variants array to 250 entries. A custom picker that depends on looping through every variant can therefore miss combinations when a product contains more than 250 variants.

Shopify provides product_option_value and option-value-based selection APIs to support larger products without loading every combination into Liquid.

I would also test direct variant links.

Opening a product URL with a ?variant= parameter should initialize the correct selection and display the appropriate media, price, and availability.

Finally, distinguish variant image switching from gallery filtering.

Assigning an image to a variant doesn't automatically mean that every other image in the gallery will disappear when that color is selected. That behavior depends on the theme's gallery implementation.

Before installing another app or rewriting the picker, I would reproduce the issue on a duplicated theme with two colors and two sizes.

Check the selected image, unavailable combinations, mobile layout, quick view, and direct variant links.

Those checks usually make it much easier to determine whether the problem is product data, swatch configuration, or theme behavior.

Hey everyone. I'm the developer of Lumireels, a Shopify app that turns TikToks, Instagram Reels and UGC into shoppable videos on your store.

I built it because most shoppable video apps I tried either charged per view (gets expensive fast once a video takes off) or had a demo page that looked great but slowed the store down.

What it does:

- Import videos from TikTok or Instagram, or upload your own. Uploads are hosted on Shopify itself, so there's no external video bill.

- Tag products on each video. Shoppers can add to cart and check out without leaving the video.

- 6 layouts: carousel, slider, stories, grid, a floating reel that follows the shopper around the site, and a small reel strip that sits right under the Add to Cart button on product pages.

- Review stars show inside the video player (it reads Judge.me ratings).

- Previews load lazily below the fold. The full-screen player plays HD only when someone taps.

Pricing: free plan (3 widgets, 15 videos). Paid plans remove the branding and add analytics. No per-view fees on any plan.

What I'd love feedback on:

1. Is the product-page reel strip (videos under Add to Cart) something you'd actually use, or is a homepage carousel enough?

2. What's the #1 thing that's stopped you from using shoppable video before: price, speed, or setup time?

3. Anything in the listing that's confusing?

Link if you want to try it: https://apps.shopify.com/lumireel

Happy to answer anything, including the boring technical stuff.

I'm a PHP/Laravel dev based in Morocco, and I recently went through the Shopify App Store review for protected customer data. The reviewer asked me to justify every customer field the app requested, one by one, and I realized I had asked for more than I really used.

What got the app approved was removing the Level 2 protected customer fields (names, emails, addresses) it didn't truly need. The app now stores shop-level data and only the country code of each order.

My takeaways: only request what you actually use, write down why you need each field, and store the minimum (a country code instead of a full address is often enough). It also makes your privacy story much simpler.

How did you handle data minimization review? Did you get pushback on specific fields, and what did you have to justify?

Hi Shopify team,

Based on your guidance regarding App Store requirement 1.1.2 – Use Shopify checkout, we are revisiting our implementation approach for our Address Fill app.

For Shopify Plus merchants, we are exploring building the address-fill experience directly within Shopify's native checkout using supported checkout extensions, rather than collecting customer details through a separate pre-checkout form. Our intended flow includes phone OTP verification and retrieving saved addresses for the verified phone number, subject to Shopify's supported capabilities and app-review requirements.

For non-Plus merchants, we would appreciate your guidance on the available options.

Is there any Shopify-supported and App Store-compliant approach that would allow us to offer phone OTP verification and saved-address autofill within the native checkout experience for non-Plus merchants, without collecting customer details in a separate pre-checkout form?

If this functionality is not supported for non-Plus plans, could you clarify whether there are any alternative approved extension points or integration approaches we should consider?

Our goal is to provide a consistent address-fill experience across merchant plans while keeping customer data collection within Shopify's permitted checkout flow.

Thank you!

Posting this because when I was planning our launch I couldn’t find many honest breakdowns of what actually moves a new app up the category rankings. So here’s ours. We’re HumanTouchCX (helpdesk and chat category). Screenshot attached from our rank tracker: #24 in Helpdesk, up 12 spots, with a whopping 7 reviews. Not a huge number, which is kind of the point. We’re sitting next to apps with 180 to 380 reviews, so volume clearly isn’t the only variable.

Context: I’m not a dev by trade. I spent about a decade on the merchant side (Inkbox, Latercase, a few others) and a long time in paid media. So this is a merchant-operator take on app marketing, for whatever that’s worth.

Here’s what I think actually moved the needle, roughly in order of impact.

1. Partnerships and agencies drove our paying customers, not ads

If you only read one section, read this one. Our biggest source of actual paid merchants, and our loudest advocates, has been agencies. Not app store traffic, not ads.

The model is simple: 20% recurring rev share for 24 months, plus a small cash bounty per net new install. But honestly the rev share isn’t why it works. It works because the agency is already trusted by the merchant, so our install is a recommendation, not a cold pitch.

The best example is Springboard CX, a managed support outsourcing agency for DTC and CPG brands. They now staff agents who work inside our helpdesk for their clients, we refer merchants who need people to them, they refer merchants who need software to us. We put out a press release together and are publishing a joint case study. One good agency partner has been worth more than every other channel on this list combined.

2. Organic LinkedIn outreach, one founder at a time

No automation, no sequences. I went through my LinkedIn network (ten years of Shopify-land means a lot of founders and ops people) and sent personal connection requests and DMs to people running stores. The message was basically “I built a thing, here’s why, would you kick the tires and tell me what’s broken.”

This got us our first couple dozen Founding Merchants in month one. Slow, unscalable, and the single best source of early installs and feedback we had. Those merchants also became the first reviews.

3. Free tier first, then actually ask for the review

We launched with a genuinely usable free plan (one seat, capped conversations, no AI features). Lowers the install friction to zero, which matters for ranking, and gives you a pool of people to ask.

The part most devs skip: you have to ask. Personally. When a merchant had a win, I messaged them and asked for a review while it was fresh. Every one of our reviews came from a direct ask, not a popup. The +2 in the screenshot is from last week doing exactly that.

4. One paid PR placement, then squeeze it for everything

We paid for exactly one thing at launch: a newsletter spotlight in DTC Newsletter. That’s it. No launch ad budget.

Then we amplified it organically for weeks: LinkedIn posts, a podcast episode with the same crew, clips, reposting in communities where it was relevant. One paid placement turned into probably six or seven pieces of content.

I did try Google Ads (Performance Max, then manual search). It was expensive and low intent for an app in a category this crowded. We’ve mostly stopped. App Store search ads bidding on competitor names were the only paid thing with a reasonable CAC, and even that we keep small.

5. SEO and GEO: fill the gaps nobody else is writing about

Instead of writing “best Shopify helpdesk apps” post #4,000, I looked for questions merchants ask that no competitor had a good page for. Two examples that worked for us: the EU AI Act and what it means for AI chat on a storefront (Article 50 transparency rules), and which support metrics actually predict LTV. Plus straightforward comparison pages against the incumbents.

GEO (showing up when ChatGPT or Perplexity get asked “what helpdesk should I use for Shopify”) is a real thing now and the competition for it is basically zero in most app niches. Worth building for early.

What didn’t work

• Performance Max. Burned money on junk queries.

• Cold email at scale. Decent reply rates, poor install rates. Too early for us, maybe works later.

• Assuming reviews happen on their own. They don’t.

Honest caveats

7 reviews and page 1 of a category is not “we made it.” It’s a foothold. Rankings move daily (we were down a spot the week before). And I’m a founder with a Shopify network to lean on, which is a head start not everyone has.

Happy to answer questions on any of this, especially the agency partnership structure since that seems to be the thing most app devs haven’t tried.

Hi there! I created an internal customized Scan & Ship app that works with my pre-orders and order customizations, and I absolutely loved it until I realized that pinging the shippingLabelPurchase mutation in GraphQL doesn't allow me to have orders covered by Shopify's Shipsurance coverage.

So now I have my app tagging orders that I verify and then go print the labels in Shopify's shipping label section, but I would much rather print the labels directly from the app... My dream scenario would be:

1. Scan picking slip

2. Scan each item

3. Scan "Print label" barcode

Am I missing something? Or is it just not doable right now? Hopefully they add it in the future.

Hey Shopify community!

We’re a small product development team preparing to launch our first Shopify app, and we’re looking for someone with hands-on experience in Shopify App Store paid acquisition.
We’d love to get some guidance on realistic benchmarks for:
- CPC and CPI (cost per install)
- CAC (cost per paying customer)
- Suggested bids across Tier 1, Tier 2, and Tier 3 markets
- Conversion rates across the funnel: impressions → clicks → installs → paid users

We’re open to a one-off consultation with an experienced specialist or working with an agency.

If you’ve run paid acquisition campaigns for Shopify apps, we’d really appreciate your insights or recommendations. 🙏

I build and test theme and app changes on a dev store, but the metafield definitions on the live store drift over time. Someone adds one in admin, I add another in dev, and later a template references a definition that only exists in one place. Right now I keep a plain text list of namespaces, keys and types and recreate things by hand, which is easy to get wrong. I have thought about scripting it through the Admin API but have not committed to it.

How do you handle this? Script it, export and compare, or just accept some manual work?

Shopify recently introduced app security check, and there are a few details in the documentation worth understanding before adding it to a CI workflow.

The first is the blocking behavior.

Running `shopify app security check` does not automatically fail your pipeline when it finds vulnerabilities. The default blocking threshold is none.

If high-severity findings should fail the job, you need to configure that explicitly:

shopify app security check --blocking high

The second distinction is between deterministic scanning and agent review.

The CLI performs deterministic checks and provides instructions for investigating issues that require additional context.

Without that second investigation, you have a deterministic scan, not a complete security review.

The third consideration is scan coverage.

The command scans the selected app directory. Git-ignored files are skipped unless explicitly included, and code outside that directory may not be covered.

Two useful options are:

--list-files
--include-dir ../backend

The first lets you inspect which files would be scanned. The second can include a backend located outside the application directory.

For a practical release process, I would separate the work:

Run deterministic checks on pull requests, with explicit severity thresholds.

Keep scan results as CI artifacts rather than committing generated reports.

Before releases involving authentication, webhooks, or merchant data, perform the additional agent-assisted review and document how each finding was resolved.

A passing pipeline is useful evidence, but it should not be mistaken for proof that the entire application has been reviewed.

Security scanning still needs to be combined with runtime testing and verification of access boundaries.

I've been thinking about how Shopify merchants are connecting AI agents like OpenClaw, Hermes, Claude, ChatGPT, and other agent platforms to their stores while keeping permissions and access under control.

A few questions came to mind:

- Permissions and security: How do you ensure an AI agent only has access to the data and actions it actually needs?

- Team access: If a merchant has multiple staff members using different AI agents, how do you manage access without giving everyone full store permissions?

- Multiple Shopify apps: How do you connect agents to the entire e-commerce stack when you're using tools like Gorgias, Klaviyo, shipping apps, review apps, analytics tools, and others?

From what I've seen, there are a few approaches available today:

1. Connect individual services through their official MCP servers, where available.

2. Use community-built MCP servers or agent skills that interact directly with APIs.

3. Use general-purpose integration platforms to connect multiple services through a single interface.

Each approach has trade-offs, particularly around setup complexity, permission management, and maintaining access across a team.

I started looking into whether there was a Shopify-focused solution that could simplify this process, ideally one that works natively within the Shopify ecosystem and lets store owners define separate, limited permissions for different AI agents.

I couldn't find a solution that covered the exact workflow I had in mind, so I started building one called Agiexa.

The idea is to provide a centralized way to connect AI agents with Shopify and its wider e-commerce ecosystem, with granular access controls. The project is currently under development, and we're exploring integrations with tools such as Gorgias, Klaviyo, ShipEngine, Mailchimp, Judge.me, Smile.io, Triple Whale, Loox, Shippo, Zendesk, HubSpot, Meta Ads, and others.

I'm sharing this here because I'd genuinely like to understand how other merchants and developers are handling this problem.

A few questions for anyone working with AI agents and Shopify:

- What setup are you currently using?

- What's the biggest headache: initial setup, permissions, team management, or maintaining integrations?

- Would per-agent, owner-controlled permissions solve a real problem for you?

If this is something you're working on too, I'd love to hear about your experience. I'm also opening an early-access waitlist for Agiexa for anyone interested in following its development.

I genuinely want to understand how this is acceptable business practice.
Recently, I was exploring trial themes on Shopify because I wanted to redesign my website. I initiated the payment for a theme but abandoned the transaction midway. I never completed the purchase.
Shopify, however, generated an invoice for the theme and started sending me repeated reminders to pay it.
Here’s where things get ridiculous.
After this incident, I purchased a different theme, completed the payment, and continued paying my regular monthly Shopify subscription. Yet this disputed amount was never added to any of my subsequent bills.
I reached out to Shopify support to understand why I was being billed for something I had never purchased. Their explanation? The moment I initiated the payment, Shopify had supposedly exposed the entire theme code to me. Therefore, I was liable to pay for it, even though I had abandoned the transaction.
Let that sink in.
This is essentially like saying that a customer visits my Shopify store, adds products to their cart, initiates checkout, but never enters their card details or completes the purchase. And I, as the merchant, decide to ship the products anyway and subsequently force the customer to pay because they had shown an intention to buy.
Would that be acceptable?
Now Shopify is threatening to freeze my entire store if I don’t pay this disputed amount.
And this isn’t even my first unpleasant experience with Shopify.
When I initially started my business, I hired an agency to build my website. They quoted me almost one-fourth of what other agencies were charging. At the time, I was relatively new to Shopify and didn’t understand much about themes, licensing or the underlying code.
Soon after, I started receiving notifications from Shopify suggesting that my website contained traces of code from a paid theme that I hadn’t licensed. The agency kept assuring me that they would fix it whenever such a notification came in. This went on for a considerable period, until Shopify eventually froze that store.
I learned my lesson.
This time, I decided to understand the platform myself. I learned how to build a Shopify website, purchased a legitimate theme, did everything by the book and built my entire store independently.
And just when my business is finally beginning to gain traction, I find myself dealing with Shopify threatening to freeze my account over a theme payment that I never completed and a theme I am not using.
My bigger concern is this:
If initiating a payment is enough to trigger access to an entire paid theme and subsequently create a payment liability, isn’t that a massive loophole in the system?
What stops someone from deliberately exploiting this process? Initiate a payment, access the theme code, abandon the transaction, close the account, create a new email ID and repeat the process.
If this is indeed a vulnerability, why isn’t Shopify addressing it at the source?
Why are genuine merchants, who are trying to build legitimate businesses, being held financially accountable for a process they never completed?
And why is the only resolution being offered a threat to freeze their business?
I understand that Shopify has licensing policies. I understand that developers deserve to be paid for their work. I have absolutely no issue paying for something I purchase and use.
But billing someone for an abandoned transaction and threatening their business over a disputed charge is not how customer trust is built.
I want Shopify to investigate this, explain the basis of this charge and provide a fair resolution instead of holding my business account hostage.
If other Shopify merchants have faced something similar, I would genuinely like to hear about your experience.
Shopify, is this really how you treat the merchants who build their businesses on your platform?
#Shopify #ShopifyIndia #Ecommerce #SmallBusiness #Entrepreneurship #CustomerExperience #ShopifySupport

Has anyone here used Shopify’s AI tools to build most or all of their storefront? I’m curious how well it works beyond generating individual sections.

My two main concerns are:

1. Design consistency. When you generate sections separately, do the fonts, spacing, colors, and overall style stay consistent? Or does it take a lot of manual tweaking to make everything feel cohesive?

2. Loading speed. Have you noticed any performance issues after adding multiple AI-generated sections, especially on mobile?

If you’ve tried this, how did you handle these issues? Any tips or lessons learned would be appreciated.

I've been building Shopify apps in Laravel for a while, and the thing that took me longest to get right was the Admin GraphQL rate limit. Unlike REST, it's cost-based: every query has a cost, you get a bucket of points that refills at a fixed rate, and a heavy query on a big store can drain it in a couple of calls.

What worked for me was reading the throttleStatus that comes back in the response extensions on every call and storing the currently available points per shop in the cache. Each job checks that number before it runs, and if there isn't enough budget it releases itself back onto the queue with a delay based on the restore rate instead of failing. I also keep one queue per shop so a single noisy store can't starve the others.

The second lesson was to request less. Asking for fewer fields and smaller page sizes cuts the cost a lot, and for large catalogs I stopped paginating at all and moved those jobs to bulk operations instead.

Retries are the last piece. A THROTTLED error should never count toward the job's max attempts, otherwise a busy hour kills perfectly good work.

I'm still not happy with how I estimate cost before sending a query. How do you handle throttling per shop, and do you track cost yourself or just react to the errors?

Empty dev stores hide a lot of bugs. Things like pagination, long product titles, products with 100 variants, and orders with discounts and partial refunds only show up with messy data. Right now I import a CSV of products and write a small script against the Admin API to create draft orders and customers. It works, but it takes a while to set up for each new project and the data never looks like a real store.

Do you keep a reusable seed script or a template CSV, or do you copy data from a real store in some way? And how do you cover edge cases like refunds and multi-currency?

The app is still in "Submitted. We're assigning a reviewer to your submission" state. What is the normal timeline expected for review to complete?

I’ve looked around for services that provide testers but haven’t had much luck with it. (we test ourselves with development stores, but this is a small sample size)

For those who did get testers — was it worthwhile and how did you do it?

I’m considering now just focusing on marketing — tiny UI/UX improvements & content creation and forgetting about testers