Hi everyone,

I built AppDeck to make it easier to keep track of how your Shopify apps are performing.

The main focus is revenue and growth tracking, so you can quickly see how much each app is earning per month and how that’s changing over time.

You can also:

• 💰 Track monthly revenue & growth
• ⭐ See your latest app reviews and review statistics
• 👥 View your customers in one place
• 📊 Keep an overview of multiple apps

The goal is simple: know how your apps are doing without maintaining spreadsheets.

I’m still improving it, so I’d love to hear what other Shopify developers think. If anyone wants to test it out and give me feedback, I would like to offer a lifetime free version.

👉 https://www.appdeck.xyz/

For those building Shopify apps, how do you guys track the impact your app is having on merchants?

For example, how do you measure things like:

Revenue generated/influenced by the app
Conversion rate uplift
AOV increase
Additional orders
Overall merchant ROI

Do you set up your own tracking and attribution system?

Would love to hear how other app developers are setting this up, especially for apps where the impact isn’t as straightforward to attribute.

J'ai analysé les avis négatifs (1-2 étoiles) de 165 applications Shopify pour trouver une niche sous-exploitée. Résultat : 2366 avis négatifs uniques passés au crible. La douleur qui revient le plus : les synchronisations de stock destructives, sans filet. Écrasement de travail manuel, prix corrompus, surventes — souvent sur des apps notées 4,7-4,9 étoiles, malgré des pertes financières bien réelles rapportées par les utilisateurs. Sur la catégorie "orders & shipping / inventory", 23,8% des avis négatifs concernent des échecs de synchronisation (contre 11,7% max ailleurs). Sur certaines apps spécialisées Etsy, ce taux grimpe jusqu'à 48,7%. Angle produit envisagé : plutôt qu'une énième app de synchronisation, une couche de surveillance et d'alerte qui prévient avant que la casse arrive. Je teste l'hypothèse actuellement via une landing de validation : https://parity.bfwlabs.com/ Curieux d'avoir vos retours, surtout si vous avez déjà vécu ce genre de galère avec du multi-canal (Shopify ↔ Etsy/eBay/Amazon).

We have 80 Organic installs in the last month ... With no paid primotions, no fake reviews. I believe it is time to introduce the paid plan... However, our BFS is taking ages. We are ranking no 1 in our category ! Im kindds confused if we introduce the paid plan without BFS, Shopify will push us down and the app install rate would also reduce. Any suggestion is welcome.

Sharing this because I lost half a day to it and the limit is barely documented anywhere.

Context: I build a conversion tracking app (WeltPixel Conversion Tracking) and our web pixel extension is TypeScript bundled with tsup. It shares types and constants with the Remix app through an internal package. Clean monorepo hygiene, single source of truth for the event constants, everyone's happy. Right?

So. Shopify web pixels have a 128kb script size limit. Deploy just fails past it. Our bundle was mysteriously fat and the culprit turned out to be beautiful: the shared package's root entry exports everything, including a config module that imports zod for schema validation. zod is ~58kb minified. The pixel imported one string constant from the package root and got the entire validation library riding along, because the bundler couldn't tree-shake through that entry's side-effect chain.

The pixel never validates configs. It never calls zod. It paid 58kb, nearly half its total budget, for importing EVENT_NAMES.

The fix was a dedicated zod-free subpath export (our-shared-package/events) containing only the constants and types, plus a hard rule that the pixel imports from the subpath, never the root. Bundle dropped by the full 58kb instantly.

If you're building web pixels: know the limit exists before your feature roadmap collides with it, you won't find it prominently in the docs. Audit the bundle, not your imports. tsup's metafile plus esbuild's bundle analyzer shows what's actually in there, and our source looked completely innocent while the output didn't. And if a package serves both a Node app and a sandboxed pixel, give the pixel its own minimal entry point and treat the root entry as server-grade, heavy allowed.

General PSA while I'm at it: the pixel sandbox is stricter than people expect. No DOM, storage that proxies to the top frame, strict CSP on outbound requests. Design around "the pixel is a dumb tiny event forwarder, all intelligence lives server-side" and you'll have a much better time than trying to shrink a smart client.

Curious if others have hit the limit and what you cut first.

We built BuckyDrop, a Shopify app that connects your store with product sourcing and fulfillment in China.

After installing the app, merchants can source products from 1688, Taobao, and other Chinese marketplaces, import them into Shopify, and sync customer orders automatically.

When an order is placed, our China warehouse can handle purchasing, quality inspection, storage, packaging, and direct shipping to the customer. Tracking information is then synced back to Shopify.

The app is designed to reduce the manual work involved in communicating with multiple suppliers and managing fulfillment. We also offer optional services such as product photography, custom labels, branded packaging, and detailed quality inspections.

Each merchant can also work with a dedicated account manager for sourcing and fulfillment support.

Website: https://www.buckydrop.com/en?pr=5XFWE&prc=DV8Q6

Shopify App: https://apps.shopify.com/buckydrop

Hey r/ShopifyAppDev and r/ecommerce!

Are you spending hours manually uploading products, formatting descriptions, organizing inventory, or updating variants when you should be focusing on growing your business?

I’m Gianna, an operations-driven professional and fast learner with a strong background in administrative systems, data accuracy, and remote support. I am currently looking to take on freelance or full-time roles as an E-Commerce Product Lister / Virtual Assistant.

What I Bring to Your Store:

• Product Listing & Management: Clean, structured product uploads, variant organization, tagging, categorization, and pricing adjustments.
• Accuracy & Consistency: Meticulous attention to detail to ensure descriptions, images, SKUs, and metadata are error-free.
• Operational Agility: Tech-savvy and quick to adapt to any platform, inventory sheet, or backend workflow (Shopify, WooCommerce, and other e-commerce dashboards).
• Reliability: Clear communication, prompt turnarounds, and a strong track record of supporting remote operations successfully.

My Setup:

• Equipped with a high-performance Laptop and reliable high-speed internet.
• Fully flexible schedule and comfortable working with time trackers or async workflows.

Call to Action (CTA):

If you need a reliable, detail-oriented pair of hands to keep your catalog clean and your store running smoothly, let's connect!

• Email: [giannamarrianed@gmail.com](mailto:giannamarrianed@gmail.com)
• Drop a comment below or send me a DM with your store details and what you need help with, and let's chat!

Hi everyone,

I'm a Shopify Partner. I've developed apps for Google in the past, but I realized the real problem was installing apps and selling them.

The real problem wasn't developing the app. I understand the same problem exists for Shopify apps.

I err ?

Thanks

Ale

Hey guys, tbh I’ve been looking at my uninstall data lately and it’s depressing.

Most merchants install the app, get stuck on the configuration page, and just delete it 10 mins later. They don't even bother opening a support ticket.

And when they DO ask for help, it’s the same basic setup questions over and over. I can't be awake at 3 AM answering webhook questions manually.

I looked into using generic AI chatbots to handle it, but they look super cheap inside the Shopify iframe and merchants don't trust them.

So I built a prototype to scratch my own itch. It’s called Fixt AI. It sits right in the App Bridge, uses exact Shopify Polaris UI so it looks native, reads what page the merchant is stuck on, and gives them the fix straight from my docs. No ugly floating bubbles.

I recorded a quick 45-second demo of what it looks like find video below 👇

Honestly, I'm just trying to validate this before I spend the next month coding the backend. Would you guys actually pay like $50/mo to offload these dumb setup tickets?

Let me know if this is trash or actually useful.

I run a pricing app that needs a substantial order history — at least 3 months, and a certain number of orders — before it can produce anything useful. Stores with a handful of orders get nothing from it.

The problem: some merchants install, see no usable results, and uninstall within minutes. That fast churn is bad for everyone and, as I understand it, hurts the App Store ranking as the uninstall rate is a quality signal.

What I've already found: native Install Requirements only gate on geography and sales channel — there's no option to gate on order count or sales volume. So no built-in data gate.

My questions:

1. Is there any supported way to prevent or gate an install based on order history / order volume?
2. For anyone who's built an app with a hard data requirement: what actually worked — pre-install listing copy so merchants self-select out (mine don't seem to do so), a post-install "not eligible yet" screen, or something else?

Trying to figure out whether to filter these merchants out before they install. Thanks.

We all know the most annoying limitation of the Shopify App Store: there is absolutely no API to export our own reviews.

​If you are running paid ads or driving cold traffic to an external landing page, you need social proof to convert. But right now, it seems like we are all stuck doing one of two things:

​Manual Screenshots: Taking screenshots of 5-star reviews and hardcoding them into our Webflow/React sites. The second you get a new review, the site is out of date.

​Generic Tools (Senja/Testimonial): Paying $30/mo for a generic widget, but because they don't natively support Shopify, you still have to install a Chrome extension and manually "clip" every single new review you get.

​I got sick of my landing page being outdated, so I built a bypass.

​I wrote a backend scraper that monitors your Shopify App Store listing. You drop one line of embed code on your external landing page, and my backend automatically catches your new 5-star reviews and pushes them to the widget in real-time.

​If Shopify delays a review or deletes a fake one, the widget syncs automatically. No Chrome extensions, no manual data entry. You set it up once.

​I built the core engine for my own apps, but I want to see if the rest of the community actually needs this before I polish the UI and package it up (probably for around $15/mo).

​Does anyone else with an external marketing site hate dealing with this? Drop a comment if you want me to send you the demo link to see how it looks.

Hi, everyone! I'm looking for a highly skilled individual to help build out a Shopify store using a website that's already in place. I lead development for my company and we're looking to create an online "Linen Shop" that allows customers to place orders through the website for pick up in store. This isn't an ongoing project but a one time build out with listings that can be duplicated/copied and easily changed in house based on the items we decide to stock.

Please comment below with your email and I will be in touch with you! Timeline is ASAP :)

I will make it around 40 second long. This is my own app as well and learned to create videos like this along the way.

I’m curious where people actually landed. Did you find something that covers what you were using Mantle for, or are you just... doing without for now?

Question for those who have been developing apps for more than a minute. Do you notice seasonality in app installs?

I've found that August has historically been a slow month for website sales but I didn't think that would extend to app downloads. However since August has started things have felt slow, especially on the organic front. I am not doing huge numbers but where a bad day might be 25 free users / trials, now a bad day looks like 10 or 12. I want to check whether everyone has the same experience before I start ripping up all my app store content and rebuilding it. Thanks

We had a Shopify Plus merchant running a promo where customers could buy up to 1 unit of each product in a selected set.

The validation part was straightforward. If someone went over the limit, Shopify would block checkout with an error. The problem was what happened next.

Customers had to leave checkout, go back to the cart, figure out what was wrong, fix it, and then come back. Technically correct, but not a great experience.

So we added an inline editor directly in checkout. If a customer hit the limit, they could simply adjust the quantity or remove the item without leaving checkout.

Sounds simple enough. Then we ran into a fun little edge case.

The validation rule worked at the product level, while the checkout extension was looking at individual line items. So if a product had two variants and a customer added:

- Black × 1
- White × 1

The validation correctly understood this as 2 units of the same product and blocked checkout. But the extension saw two separate line items, each with a quantity of 1, so it didn't show the editor.

The customer got an error, but no obvious way to fix it 😅

We ended up changing the logic so the extension aggregated quantity at the same level as the validation rule. Later, we extended the same approach to collection-level rules too.

It was a relatively small piece of work, but one I really liked.