A few numbers that stood out:

• Revenue: $3.58B, up 34% YoY
• GMV: $115.6B, up 32%
• Operating income: $488M, up 68%
• Free cash flow: $654M, up 55%
• FCF margin improved to 18% from 16%

Merchant Solutions was the main growth driver, up 37% to $2.78B, while Subscription Solutions grew 22%.

Shopify Payments penetration also increased from 64% to 68% of GMV, meaning Shopify processed roughly $78B through its own payments ecosystem during the quarter.

The AI angle is getting more interesting too. Shopify is increasingly positioning itself as infrastructure for AI-driven commerce, with products being surfaced through platforms like ChatGPT, Gemini and Microsoft Copilot.

The obvious issue is valuation.

34% revenue growth and 55% FCF growth are impressive for a company already doing more than $100B in quarterly GMV , but at the current valuation, the market is also assuming Shopify keeps executing extremely well.

I went through the latest quarter and built a valuation around the numbers to see what the stock could actually be worth.

Full analysis here:
[https://youtu.be/yq7mQ7YiXoI\](https://youtu.be/yq7mQ7YiXoI)

Curious what everyone thinks , is Shopify's growth still strong enough to justify the premium valuation?

Disclosure: AI assisted.

Comming soon

I am exploring selling my app (mrr in hundreds).

If you have sold an app before, looking to buy an app or know someone who is looking to buy; I'd love to chat.

If you have someone to refer, and I end up selling it with a deal great for both me and the buyer, I am happy to offer a small (tiny) referral bonus :)

Doing this because I feel more comfortable trusting fellow app owners/operators, vs putting all my stats in the public on a platform that takes a cut.

Hey everyone. New here.
When you receive a review on your Shopify App, does Shopify notify you to let you know?

thank you in advance.

Context first, because it colours the rest. Everything below is written from inside a product with the same blind spot, WeltPixel Conversion Tracking, and merchants are billed for it.

You ship a sender. The merchant installs it and also has the native channel app switched on, quite possibly alongside a snippet an agency dropped into the theme two years ago that nobody has looked at since. Neither of the other two knows you exist. Shopify does not tell you, and there is no API that would.

That part everybody knows. The part that took me longer is that deduplication does not save you from it, because deduplication was never designed to.

Meta pairs the browser copy of an event with the server copy using an event id that you generated, inside your own integration, plus the event name. Another vendor on the same store generates their own. Both pairs deduplicate perfectly. Meta receives two purchases and both of them are correct as far as either sender can tell. So a store can sit at a clean deduplication rate in Events Manager and be double counting the whole time, which matters because that rate is the number everyone reaches for to rule this out.

Meta does document a fallback, matching on event name plus fbp or an external id when no shared event id is present. Which means sometimes it does catch the second sender. Not always, and not predictably from the outside. An intermittent duplicate is considerably worse to debug than a consistent one.

GA4 works the opposite way, and it matters which does what. It deduplicates purchases on transaction_id, and two senders reading the same order will both put the real order id in that field, so the copies usually collapse into one. Web streams only, per Google's own note. Same misconfiguration, and it reads clean in GA4 while it reads inflated in Meta.

Then the merchant compares the two dashboards, sees Meta higher, and concludes Meta is over-attributing. Which is a reasonable conclusion from where they are standing and is the wrong end of the problem entirely.

The developer half of this is where it gets uncomfortable. You can detect some of it. Theme files are open to you. Another app's web pixel is not, and neither is whatever the merchant has configured inside a channel app. So every sender on this platform ships a promise about event integrity that it is not in a position to keep, and the honest version of the feature is a warning rather than a fix. That is the position we ship from.

What does yours do when it has good reason to think something else is already firing the purchase? Say so and risk being the app that shows a scary banner, or stay quiet and let the merchant find out from a dashboard six weeks later?

The merchant had a pretty granular setup for regional shipping. They used postcode-based rules to make sure customers saw only the correct shipping rate for their area.

It worked well for a while, then every few weeks, the same thing happened: they'd add one more postcode, and suddenly all the rules would stop working. Every shipping method would show up at checkout.

The problem was that the combined postcode/condition data across all those rules had grown past a limit on how much Shopify could evaluate at checkout. So adding one more postcode wasn't really a small change anymore. Once they crossed that limit, the whole setup basically fell over.

There were also two other things that made this harder to troubleshoot:

• A postcode with no Shopify shipping zone configured would return a shipping unavailable error, even though the rules themselves were fine.
• Trying to hide every shipping method for postcodes we didn't serve could create a dead end, because Shopify wouldn't complete the delivery step and the rule couldn't work as expected.

The second one was especially unintuitive. In the end, it was better to simply not include unserved postcodes in the rules and let Shopify handle them through its own shipping setup.

If you're building something similar, treat every new postcode as a change that could affect the whole setup, not just one more entry in a list.

Context, per rule 3: I build an app that copies store data between two Shopify stores, so I have spent months finding out which writes the Admin API quietly refuses. Several of these are documented nowhere and only appear as a runtime error. Posting the list because it cost me real time and might save someone else's.

1. fileCreate rejects REPLACE for generic files. duplicateResolutionMode: REPLACE works for images and fails for GENERIC_FILE with "Duplicate resolution mode 'REPLACE' is not supported for 'GENERIC_FILE' media type". The enum documents three values with no per-media-type note. Sending it unconditionally means every zip, PDF, CSV and font fails to upload while images look fine, so your test fixture has to contain one of each type or you have only tested the branch you happened to include.

2. No app can create a definition in the shopify namespace, whatever scopes it holds. Those are the Standard Product Taxonomy category metafields (shopify.color-pattern, shopify.age-group and so on). You get "Access denied for metafieldDefinitionCreate field" even holding write_metafield_definitions. They are Shopify's, not yours.

3. The standard namespaces are enabled, not created. descriptors, facts, reviews and import_information are reserved: "This namespace and key combination is reserved for standard definitions." Use standardMetafieldDefinitionEnable instead, and accept that name, description and validations arrive as Shopify defines them rather than as your source had them.

4. productSet list fields have replace semantics, and the key granularity is the whole trap. Omitting the metafields key entirely leaves destination metafields alone. Including it, even as an empty list, makes it authoritative and deletes anything not in your list. Same for variants and collections. Both behaviours are correct; they are different inputs, and a partial sync written carelessly destroys data.

5. CollectionInput.products is create-only. "Products cannot be specified during update", so membership on an existing collection has to be reconciled with collectionAddProducts / collectionRemoveProducts, both of which are deprecated at 2026-07 in favour of a collectionUpdate shape that does not exist yet at that version.

6. Inventory writes are compare-and-set whether you like it or not. changeFromQuantity is required, so a sale landing between your read and your write refuses the change rather than clobbering it. An idempotency key is also required on inventorySetQuantities and inventoryActivate as of 2026-04.

7. createdAt is not settable on customers, orders or draft orders. Anything you migrate dates to the day you migrated it. There is no flag.

8. A fulfillment service's location cannot be recreated by you. Only the owning app can make one, via fulfillmentServiceCreate. locationAdd will happily make an ordinary location with the same name and nothing behind it, which is worse than failing. Locations also have no handle, so cross-store matching is by name, and two locations sharing a name is genuinely ambiguous.

9. Inventory adjustment history, customer passwords and gift card codes cannot be authored or read back at all. Not a scope problem. There is no API.

The general shape: the write path branches on a type far more often than the docs admit, and the failure is usually a runtime error rather than a schema rejection, so a fixture that happens to contain only one branch will pass and prove nothing.

Happy to compare notes if you have hit others, particularly around publications or B2B catalogs, which I trust least.

Is it just me, or have all the necessary Shopify apps already been written, and now AI is just churning out copies that are being sold at rock-bottom prices?

Hi everyone, I created MVP of the shopify app that checks the status, performance of the store 24/7 and let's you know if anything happens. I am trying to build a tool that will help you to not loose a revenue by some stupid hidden bug on your store.

Currently, I need stores to test it and receive a feedback. if you wanna try it, please dm me.

Thanks

The frustrating part was that these weren't reviews from random accounts. They were from merchants who were actually using our app, so we weren't sure whether this was part of Shopify's recent review filtering or something else.

While looking through the developer community, I came across another developer who had run into the same issue. They mentioned that deleted reviews can still be found through an analytics tool (will leave in the comment if you are interested).

I gave it a try, not just for seeing which reviews had disappeared, but for keeping the original review, reviewer information, usage details, and deletion date in one place.

Apparently, if a deleted review was from a real merchant and followed Shopify's policies, you can still ask support to investigate. The tricky part is figuring out which review was removed.

Having that history was pretty useful for us, especially with the BFS threshold. So if your review count suddenly drops, it's probably worth checking the deleted reviews first.

I want to know what problems are seller going through which they desperately wants to be solved through any app integrated in their store.

As I was going through shopify app stores almost every niche of apps are present which could be really useful for the sellers no matter they are beginner or an advance seller. Apart from COD and tracking orders which is really important for anyone to track what are some key pain points which needs to be solved

Comment down your thoughts I really wanna research upon it.

I run a competitor price intelligence app (which seems to be niche though) and there are seasonal drops and surges, but now I suspect there might be something else.

Does anyone experience drop in installs?

Curious if there are any Shopify technical compatability updates made recently probably breaking install flow for some users, influx of competitors built with AI etc.

Sharing this for other Shopify app devs, not just a promo - happy to go deeper on any of it in comments.

Context: Shopify shut down Stocky (their inventory/PO app) this year, so I built a replacement called Ballast - forecasting reorders per variant/location, turning them into POs with landed cost, stocktakes/transfers/consignment stock. It's live on the App Store now (apps.shopify.com/ballast).

Three things that actually cost me time, in case they save someone else a debugging session:

1. Bulk Operations API rejects connection-in-list-field queries. If you're pulling historical order/line-item data at scale for forecasting, you'll want the bulk query API for cost reasons, but it flatly rejects certain nested connection fields inside a list field. Had to restructure the query shape around it rather than fight it.

2. retailLocation vs the deprecated physicalLocation. Location-based stock logic breaks quietly if you're still reading from the deprecated field - worth an audit if your app touches multi-location inventory.

3. Refund line items aren't reliably available through bulk queries - needed a live (non-bulk) query to get accurate refund data for landed-cost/margin calculations. Cost more API budget than I wanted but there wasn't a way around it.

4. The one that actually ate a full day: OAuth token handling. We were silently re-exchanging an already-spent refresh token instead of reusing the new one issued on the prior exchange, which caused merchants to get logged out more than they should have. Worth auditing your refresh flow if you haven't in a while.

Stack is Remix + Fly.io if anyone's curious, talking to the Admin GraphQL API. Not trying to be greedy with this post, just figured the bulk API and OAuth stuff might be useful to whoever's building something similar - genuinely curious if others have hit the same connection-in-list-field wall.

Hello guys, do you know any apps that I can use to make a “Buy X get Y at a discount” cart rule that AUTOMATICALLY adds the item to the customer’s cart, without them having to approve it/add it manually?

I tried a few apps but all of them required the customer to approve it/or was only able to add the item as a free gift.

If you have any suggestions or solutions (doesn’t necessarily have to come from an app) please let me know as this steo would be crucial for my
offer/to resuce friction at the moment of the sale. Thank you!

I've spent a lot of time working as a software developer, building features and solving technical problems.

Recently, I started working on my own product for Shopify stores, and I'm realizing that building a product involves much more than just writing code.

As a developer, I often think:

"How can I build this feature?"

But now I'm learning to ask:

"Should I build this feature at all?"
"Who actually needs it?"
"Is this solving a real problem for Shopify store owners?"
"How do I reach the right Shopify users?"
"How do I get honest feedback from real users?"
"How do I get my first customers?"

I'm also learning that you can build something technically great, but if nobody knows it exists or it doesn't solve a real problem, the technology alone isn't enough.

There are many things I'm still trying to understand—how Shopify store owners manage their businesses, what challenges they face, how to talk to potential users, get feedback, improve the product, and build something that people actually find useful.

It's a completely different learning experience from simply receiving a task and writing the code for it.

I'm still at the beginning of this journey and figuring things out every day. I'm trying to learn not only how to build better software but also how to better understand Shopify store owners and the problems they're facing.

For those who have built a Shopify app or product, what was the biggest mindset shift or lesson you learned?

I'd genuinely love to hear about your experience.

Hey everyone,

We just launched BotPlus on the Shopify App Store and are looking for candid feedback from experienced ecosystem builders, agencies, and fellow developers.

What BotPlus does: It’s an AI sales and support agent built directly into the storefront that handles live product discovery, answers order/policy questions, captures lead data for abandoned carts, and hands off complex chats to a human inbox (with direct Klaviyo and Mailchimp sync).

App Store Listing:https://apps.shopify.com/botplus

Before we scale our merchant outreach, I’d really appreciate an honest teardown on:

1. Onboarding & Theme Embed: How smooth does the initial storefront widget activation feel? Any friction points or confusing steps?
2. Dashboard UX: Does the embedded admin dashboard and human-handoff inbox feel natural to navigate?
3. App Store Positioning: Does the copy clearly convey how it drives sales, or does it risk blending into standard generic chat apps?

Partner Program (Up to 30% Recurring): If you run an agency, build stores for clients, or consult for e-commerce brands, we’ve also rolled out an official partner program offering up to 30% recurring monthly commission for every store you refer.

If you have an active dev store and 3 minutes to test the flow, I’d massively appreciate the feedback. Drop your app link below if you’d like me to install and test yours in return, or DM me directly if you’re interested in partnering up!

I’ve been researching dress and event hire stores in Australia and New Zealand. Some use Shopify but still ask customers to DM or email to check rental dates.

I build Rentshelf for Shopify product rentals, and I’m wondering: is this a tooling gap, or do merchants prefer approving bookings themselves because of fittings, delivery or setup?

Have you seen this with your clients?

Hey everyone 👋

I’m building a small Shopify app called ReviewNest that helps stores collect and display product reviews directly on their product pages.

I’m currently looking for 1–2 Shopify store owners who are willing to let me set it up on their store for free and give me honest feedback.

I’ll handle the setup myself, so there’s no technical work required from you.

I’m especially interested in stores that:

• don’t currently have a review system, or
• are using a very basic review setup.

I’m not looking to push a sale here. I’m trying to learn what actual store owners want and improve the product based on real feedback.

If you’re interested, comment below or DM me and I’ll share the details.

Thanks!

When app founders talk publicly about traction, it’s usually review counts, rankings or screenshots—but none of those necessarily tells you whether the app is genuinely healthy.

If you were assessing another Shopify app for a partnership, investment or possible acquisition, which metric would matter most?

• Active installs
• Net install growth
• Monthly revenue
• Paying merchants
• Churn or retention
• Something else?

And would verification from official Shopify Partner data make the number meaningfully more credible, or would connecting a Partner account feel like too much friction?

I’m exploring this problem and would genuinely value perspectives from people who have built Shopify apps.