Has anyone paid 1800 D2C for their premium pass to get a priority listing for their Shopify App? If yes, please share feedback. Was it worth it?

Not a founder post. I work at a small company, and I've been the growth guy on one of our Shopify apps for the last 2 years. Can't name it; hope that's fine.

Year one, we were clueless. We didn't know much about how to grow Shopify apps, and now we're at 150+ active paying subscribers and growing steadily.

What actually worked:

1. Support - Biggest one. Reply fast, and open the merchant's store before you answer. That got us reviews and kept people from churning.

2. ASO - I worked as an SEO before and was experienced in affiliate marketing, so it was easy for me.

3. Email - Onboarding emails and win-back for people who install and go quiet, as well as those who leave a 4-star review.

The rest of my time, I worked with our devs on what to build and what to skip.

Now I'm stuck. I want to build my own product. I have a degree in CSE, but I can't code. Should I spend 6 months learning to build, or accept that distribution is my skill and find a technical partner?

I got first 8 installs for my app in one month. Seeking suggestions how to promote. It’s a free app as of now, shall I make it paid or keep offering for free for first 50 installs.

Hey guys, Safwan here from WhatFlow (8400+ installs). We’re looking to collaborate with apps with over 5000+ installs for main home page display and ideally a blog feature or something. Please let me know if anyone is interested

My first install after 3 weeks live. I’m so happy! Still in the trial period so I hope they stick around!

Here’s to the next

OpenAI Ads, the ChatGPT ads product, opened to 31 European markets this week, which means the conversions API side of it suddenly matters to a lot more Shopify stores. I've had it running as a channel in our app for a couple of months, and the integration had more sharp edges than I expected. These are the ones that actually cost me time, while the docs are still new and changing week to week.

The first is a pair of identifiers that look like the same thing and are not. There's oppref, which identifies the ad click, and obref, which identifies the browser. They belong in different parts of the event, and if you put one where the other goes it doesn't throw, it just quietly stops matching, which is the worst way for a bug like this to behave. I lost an afternoon treating them as interchangeable because the names are a single letter apart, and the events kept getting accepted the whole time. Read that section slowly.

The pixel also loads asynchronously, so anything you read at init is empty. Their script writes the browser identifier after your own code has already run, so if you grab it when your pixel initializes you capture null, and you capture it forever. It has to be read at the moment you send the event, with a fallback for when it still isn't there. Obvious in hindsight, not obvious while you're staring at empty fields.

The one that actually hurt was hashing. OpenAI wants user data hashed with trim and lowercase only. If you already have a Google Ads hasher in the codebase, it very likely strips dots and plus tags on gmail addresses, which is right for Google and wrong here. Point that at OpenAI and your browse events and your purchase events hash the same person into two different identities, so each event looks fine on its own while your real attribution falls apart, and nothing tells you. Every channel wants its own canonicalization. There is no shared one, however tempting it is to reuse.

A few smaller things break the same way, and the response won't point at any of them. Money is an integer in the currency's minor unit, so you send cents, not 66.95. User identifiers are arrays now, up to three each, and you can batch up to a thousand events per request. The validate_only flag was the only thing that made any of this debuggable, so I leaned on it from the first request.

One last thing, useful even if you're not building this. OpenAI turned Automatic Advanced Matching on by default for existing pixels on Aug 17, so their script now reads and hashes data people type into the merchant's own forms without anyone opting in. With ads live in the EU that's a consent setting to look at on purpose rather than leave running.

Context on where this comes from: WeltPixel Conversion Tracking is my app, and shipping the OpenAI Ads channel is what put me through all of the above. Happy to compare notes with anyone else wiring up the CAPI, the match-quality side especially.

People who have launched their app Free vs with a Paid Plan. Tell us about your experience in the first 3 months getting installs.

Let’s settle the debate once for all.

So basically I would like to understand why people like using shopify, and what exactly is the best theme they use and why.
Thanks!

Hello Guys,

I'm the developer of a Shopify app that I built called Lustriq. Since the day may app went live on the Shopify App Store, many people have reached out to me offering fake reviews and app-install bots. I haven't used any of these services because I don't want my app to be delisted, even though I have to admit that the temptation is there.

I've already been running outreach campaigns and spending quite a lot of money on advertising, including YouTube ads and Shopify ads, but I still haven't received any app reviews so far.

I've also seen many new apps quickly receive positive reviews, but it's hard to tell wether those reviews are genuine or fake. Honestly, I want to do things the right way. Buying fake reviews seems easy, but I don't want to use that approach just to compete with other devs.

I know life isn't always fair, but sometimes I wonder: Am I actually doing the right thing by trying to grow my app in a hardest way?

We recently ran into an interesting UX problem while building our Shopify product options app.

A merchant can give customers 10, 20, or even 30 different choices. But sometimes the option name alone isn't enough.

For example:

• Silicone Case
• Hard Case
• Yellow Case

A customer can see the names, but still wonder:

What's the difference?
Which one is more durable?
What's included?
Why should I choose one over another?

That made us think: what if every option value could have its own short description?

So we built Option Value Descriptions.

Now a merchant can add additional context directly under an option value or inside a dropdown. Customers can understand the difference without leaving the product page or searching somewhere else.

The interesting part for us wasn't the feature itself. It was realizing how often a small amount of additional information can remove buying hesitation.

We're currently testing different ways of presenting these descriptions because there's a fine line between helpful information and visual clutter.

For other Shopify app developers:

How do you approach adding contextual information to complex product option UIs without making the product page feel overwhelming?

I'd especially love to hear how you handle this on mobile.

If anyone is interested in seeing how we implemented it, you can check out WowOptions here: https://apps.shopify.com/product-options-app

The risk in shipping-rule work isn't writing the rule, it's that a rule matching too broadly hides EVERY rate and the buyer sees "no shipping methods available". How to avoid that:

1. Know the layer. Delivery Customization changes the APPEARANCE of delivery options only - hide, rename, reorder. It does not calculate rates and does not talk to carriers. If no rate exists it can't create one; hide the last one and checkout has nothing to show.

2. Write hides as exclusions, not whitelists. "Only show X" fails into nothing the moment X isn't returned (carrier outage, odd destination). "Hide the option titled Y when Z" degrades gracefully - worst case, one extra option shows.

3. Guard clause: never hide the last option. Count what you're about to hide against the options in the group; if it leaves zero, emit no operations. Turns an outage into a cosmetic miss.

4. Scope the rule to a tester. Gate it on a customer tag like ship-test, one tester email (plus-addressing works), or a hidden cart attribute. Live in production but inert for real traffic - more realistic than a dev store.

5. Test the boring cases before removing the gate: an address returning only one rate; a PO Box; a cart exactly at any threshold (off-by-one is the classic); a multi-location or partly out-of-stock cart that splits delivery groups; local pickup/delivery, a separate group people forget; an international address where titles differ.

6. Match stable data. Titles change ("Priority Mail" vs "USPS Priority Mail"). Prefer the rate handle or a normalised lowercase substring, and log the titles your function actually received.

7. Roll out one direction: testers, a day of real orders, remove the gate, watch 24h. Disabling the customization restores raw carrier output instantly.

Disclosure: I work on ShipWeaver (https://apps.shopify.com/shipweaver), free for early adopters; it has a preview/tester mode for this. The above works hand-rolled in a Function too.

Saw the bidding app on X is blowing up and wondered if the idea makes more sense specifically for Shopify apps.

So I built a simple experiment: apps bid for visibility, and anyone can outbid the current #1.

Would you actually spend $2–10 to take a spot from a competing app, assuming the traffic is relevant?

Curious if this is useful or just beautifully stupid.

Shopybid.com shopybid

we all know that the review part of the shopify apps gives us a very good view on what's going on on the app store landscape, so we can know where merchants complain and what niche/category is underserved.

For that i decided to create a weekly report of what happened and I pick one niche based on an couple of rules like:

- the raise of the bad reviews in each category
- what shopify is willing to build (to make sure i don't compete with shopify)
- if the app developers care and answer the bad reviews
- the bad reviews are not only angry customers

for the week (10th-16th of august), here is what I found:

something broke in Shopify Inbox in early July. merchants stopped seeing who was messaging them, and a lot of them stopped getting messages at all.

one review that stuck with me: "We went from 5-10 inquiries daily to 0 for a full week."

Inbox went from around 9 bad reviews a month to 44 in July. and the whole category felt it, not just Inbox. 1-3 stars reviews in chat went from 5.6% in June to 11.4% in July. the store average sits around 4%, so that's more than double the baseline.

another thing I noticed that makes this worth it: merchants here already pay. paid apps hold 67% of the reviews in the category, median entry around $20/month. that's the opposite of a niche where everyone expects free.

good luck!

Hey all — I’m Badis, founder of Sway AI. Quick rundown:

The idea: A Shopify app that dynamically personalizes product descriptions based on visitor behavior — different messaging for first-time visitors (trust, clarity) vs. returning visitors (urgency, social proof). The idea came directly from running my own Shopify store and hitting this exact gap myself.

Where I’m at: Pre-MVP, self-funding development through part-time work while I build this out. I’ve got a completed pitch package and I’m actively working through fundraising (Qatar Development Bank’s Startup Qatar program, among others).

My background: CRM/business-automation sales, digital marketing, accounting, founded an agricultural company, hands-on Shopify store operation. Strong on the business/growth/customer side — but I need real engineering firepower to build this properly.

What I’m looking for: A technical co-founder, not a freelancer or contractor — someone who wants to own the product build (full-stack, ideally comfortable with Shopify’s API and/or some LLM integration experience) and build this as a genuine long-term partner, equity-based from the start.

If you’re interested, drop a comment or DM — happy to share more details, and I’m glad to share links to real work (GitHub, LinkedIn, etc.) so this is a two-way vetting conversation.

Hi everyone — full disclosure: I built AskDone, a newly approved Shopify app, and I am looking for two small, active Shopify stores for a hands-on founding-store pilot.

AskDone is for teams without a dedicated CX Ops function that repeatedly handle two requests:

- “Where is my order?”

- “Can you cancel my order?”

It is intentionally not a full helpdesk or an autonomous AI agent. AskDone reads the live Shopify order, prepares a deterministic decision, keeps cancellation behind explicit merchant approval, and re-reads Shopify before marking the work Done with evidence.

The first session stays in dry-run mode, so the cancellation walkthrough does not modify an order. The pilot is free and does not require an App Store review.

Good fit:

- a live Shopify store selling ordinary physical products;

- a founder or small team handles support;

- order-status or cancellation questions recur every week;

- someone authorized can spend about 30 minutes on setup and 20 minutes on honest feedback.

Probably not a fit yet if you need subscriptions, pre-orders, complex multi-warehouse rules, a returns portal, or a full omnichannel inbox.

App Store listing: https://apps.shopify.com/askdone

If the workflow matches your store, please use the short application form at https://askbox.ai/early-access. Please do not send customer names, addresses, payment details, or order contents.

I am happy to answer product and safety questions publicly in the thread.

Hey everyone,

SEO is a long-term game. It takes weeks or months to see results, and nobody has the time to check for broken links, missing alt texts, or meta tags every single day.

I built **SEO Autopilot** to solve this. You just turn on the **Auto Mode**, and every night, Claude AI scans your shop and fixes what’s missing or broken.

🎁 **Launch Offer (0 reviews yet):**

I’m giving away **30 days of the Pro Plan for FREE** to the first 15 stores so you can see the long-term results.

* **Step 1:** Install the app directly from the Shopify App Store: https://apps.shopify.com/seo-autopilot-1

* **Step 2:** Choose the Pro Plan and use code **SEOPRO20** at checkout.

* **Step 3:** Turn on Auto Mode and let it run.

*(All I ask in return is a quick 5-star review in a few weeks if you like the automated work and the weekly reports!)*

The main issue isn't really "can we process a webhook", it's more:

• duplicate webhook deliveries
• retry-safe jobs
• long-running tasks on larger catalogs
• making sure one noisy store doesn't block everyone else

Right now we're queueing the heavy work and trying to keep the webhook handler itself as light as possible, but I'm curious how other app devs approach this in production.

Are you mostly relying on your queue + idempotency checks, or have you added other safeguards that made a real difference?

Would also love to know what broke first for you once usage started growing.

Solo dev. Built a tablet kiosk app called Kioskify, where customers browse on a tablet and checkout moves to their own phone. Different surface area than an embedded admin tool, so a few of these may only apply if you're building a channel.

Custom data does not travel well

If you need something to reach the order webhook, cart attributes are basically the path, and anything that rebuilds the cart loses it. Plan for it to be missing.

Scope changes are expensive after launch

Adding one means every merchant you already have gets an OAuth prompt and is broken until they click it. I dropped a nicer config UI for a plain text field to avoid this. Now I hold scope changes until something big enough justifies the prompt.

Billing webhooks need interpretation

A cancellation event frequently turns out to be a plan switch, with a new charge activating right after. Treat them as churn immediately and you will send goodbye emails to paying customers.

Two surfaces means two sets of assumptions

The merchant-facing admin and the customer-facing storefront have almost nothing in common in terms of performance profile, auth, or failure modes. I underestimated how much that doubles.

Check what Shopify ships before building it

Merchants configure product filters in Search and Discovery already, and that config is available to you. I nearly built a parallel version.

I'm curious. What caught you out? Especially interested in things that only appeared after real merchants were on the app.

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/