Vet an app or extension vendor on whether they can afford to keep pace with the platform’s release clock, not on their feature list. Shopify supports each API version for about twelve months. Magento release lines run roughly three years.
There are 29,916 apps published in the Shopify App Store and live installs tracked for 8,229 of them. The gap between those two numbers is the risk you underwrite every time you click install.
Storeleads counted 3,100,790 live Shopify stores in its September 2026 state of the platform report, served by 29,916 apps published by 18,622 separate vendors. It tracks live installs for 8,229 of those apps. Most of what is sitting in the App Store right now is not running in anybody’s store.
That is not an argument against apps. A Shopify store at any real scale runs on third party software, and pretending otherwise is how founders end up paying a developer $18,000 to rebuild a subscription flow that an app does better for $99 a month. The problem is narrower than that and more fixable. The install decision almost always gets made on the feature list and the pricing page, which are the two things a vendor controls completely, and almost never on the question of whether that vendor can afford to still be shipping compatibility updates in three years.
I have watched this pattern play out repeatedly in the $500K to $2M range, which is where premature complexity does the most damage. The store adds capability faster than it adds the discipline to maintain it, and eighteen months later somebody discovers that the abandoned cart app in the checkout path has not shipped a release since the API version it was built against went unsupported. What follows is the test I would run before installing anything, and the same test run backwards on what you already have.
Every app and extension you install is a standing bet that its vendor will keep paying for compatibility work against a platform release schedule you do not control. That bet has a price, the vendor pays it every quarter, and whether they can keep paying it is a function of their revenue model rather than their marketing.
Shopify publishes the clock openly. Per the platform’s API versioning policy, a new API version ships every three months at 5pm UTC on the first day of the quarter, and each stable version is supported for a minimum of twelve months with at least nine months of overlap between consecutive versions. The current stable version is 2026-07. Translated into vendor economics, that means every app in the App Store faces a re-certification cycle roughly once a year, per app, forever. A vendor with eight apps is carrying eight of those cycles. A vendor with eighty is carrying eighty.
Magento runs the same forcing function on a longer wavelength. Adobe’s published release and support schedule shows 2.4.9 released on May 12, 2026 with regular support running to May 31, 2029, 2.4.8 released April 8, 2025 with support to May 31, 2028, and regular support for 2.4.6 having ended on August 11, 2026. Roughly three year lines rather than twelve month ones. The wavelength is longer, but the change surface is far bigger, because on Magento the merchant hosts the code and owns the upgrade.
Both shapes produce the same question for the merchant, and it is not a technical question. It is a business model question. Can this vendor absorb a recurring, non optional, non revenue generating engineering cost across their entire catalogue, indefinitely, on the money they charge? A solo developer with four apps and a $4.99 monthly price point usually cannot, which is not a character judgment. It is arithmetic.
Run five questions on any app or extension vendor before you install: who pays for compatibility, can you read the code, what breaks the day you stop paying, how public is the changelog, and how many stores actually run it. The whole exercise takes about twenty minutes per vendor and it is the cheapest due diligence available to an operator.
The first question, who pays for compatibility, is answered by the pricing model plus the catalogue size. A vendor charging a monthly subscription is funding continuous maintenance from continuous revenue, which is structurally sound as long as their install base holds. A vendor charging once and promising perpetual updates is funding maintenance from new sales, which works while the catalogue is growing and gets strained when it stops. Neither model is wrong. You just need to know which one you bought into.
The second question, can you read the code, is binary and most merchants never ask it. Encoded or obfuscated PHP means you cannot audit the thing running in your checkout, you cannot patch it yourself when the vendor goes quiet, and you cannot hand it to a developer to fix. Readable source means a bad outcome costs you a developer day instead of a rebuild.
The third question, what breaks the day you stop paying, separates capability you rent from capability you own. Ask it before you install, because the answer after you install is whichever answer suits the vendor.
The fourth question is the changelog, and it is the single most predictive signal on this list. Go find the vendor’s public release history. A vendor shipping releases monthly against a platform that changes quarterly is keeping pace. A vendor whose last release predates the current API version is telling you something they will never put on their pricing page. I made a version of this argument back in 2023 when I wrote about auditing the apps already in your store, and the support quality point in that piece has aged better than I expected: how a vendor behaves when nothing is wrong predicts exactly how they behave when something is.
The fifth question is install base, and it is the one the marketplace listing will help you with. Reviews get gamed. Install counts are harder to fake and correlate with the revenue that funds maintenance.
A Shopify app is rented capability that stops the day you stop paying, while a Magento extension is usually code you hold and can keep running, and that difference shapes your exit far more than price does. Merchants compare the monthly numbers. The number that matters is what you are left holding when the relationship ends.
On Shopify the app runs on the vendor’s infrastructure under a subscription. Uninstall it and the capability leaves with it, along with whatever configuration and historical data lived in the vendor’s systems rather than yours. That is a genuine feature for a store at $80K a year, because somebody else is carrying the hosting, the security patching and the platform compatibility work. It becomes a liability at $3M when the thing you rented is sitting in the checkout path and the vendor has just been acquired.
On Magento the trade runs the other way. Extensions are typically sold once, installed into a codebase you host, and shipped as source you can read. Magefan is a reasonable illustration of that side of the split: eleven years selling into the Magento ecosystem, a stated catalogue of more than fifty Magento 2 extensions and over four million downloads, sold on a one time licence with a year of updates and support included, and shipped as readable open source rather than encoded PHP. Those scale figures come from the vendor and I have not independently audited them. That is fine, because the part that actually protects you is the part you can verify yourself in ten minutes: download the package and read the code. A vendor who ships readable source has handed you the exit before you needed it.
Magefan is not alone on that side of the line. Amasty, Mirasvit, MageWorx and Aheadworks all run substantial independent catalogues on similar terms, and we went deeper on partner and extension selection for Magento stores separately. The current compatibility flashpoint across all of them is Hyvä, the frontend theme that replaced Luma’s roughly two hundred JS and CSS requests with two by its own accounting. An extension that has never been made Hyvä compatible is not a minor inconvenience on a Hyvä build. It is a rebuild, and it is the clearest current example of a vendor either paying the compatibility cost or quietly declining to.
Built for Shopify certifies that an app currently meets Shopify’s performance, install and rating thresholds under an annual review. It certifies nothing about the vendor’s finances, their pricing next year, or their appetite to keep shipping. Treat it as a floor, not a verdict.
The requirements for the badge are real and worth knowing. An app has to clear minimum install counts, review volumes and rating thresholds, uninstall cleanly using theme app extensions, keep checkout performance impact minimal, and stay in good partner standing. Apps are reviewed annually against those standards, developers get 60 days to fix identified failures, and repeated violations cost the status plus a three month ban on reapplying. That is meaningful governance, and it is more than most marketplaces do. Shopify has written publicly about how it polices app store quality, including automated scans, fraud detection and periodic audits that remove multiple apps at once.
Here is what an annual compliance review cannot see. It cannot see whether the vendor has runway past next quarter. It cannot see an acquisition that is about to change the roadmap. It cannot see the price increase waiting at your renewal. And it cannot see a founder quietly deciding that maintaining the small app in their catalogue is no longer worth the quarterly compatibility work. Those four risks are exactly the ones that cost merchants money, and none of them show up in a badge.
So use the badge to filter, then run the five questions on whatever survives. The badge tells you an app met a standard on the day it was reviewed. The changelog tells you whether anyone is still home.
Set the vetting bar by what a failure would actually cost you, which means under $50K you can afford to be wrong and above $2M a single abandoned dependency in the checkout path can cost more than the app saved across its entire life. The test does not change by stage. The amount of ceremony you apply to it does.
The stage that needs this most is $500K to $2M, and the reason is structural rather than moral. Our own stage by stage tech stack guide puts the average merchant at around six apps while scaling brands typically run fifteen to twenty five, with app spend moving from under $200 a month to somewhere between $1,000 and $3,000. That jump happens over roughly eighteen months, it happens app by app with each individual decision looking sensible, and nobody is tracking the aggregate dependency load until something in it fails.
Above $2M the calculation changes again, because the cost of a failure stops being an inconvenience and starts being a revenue event. At that stage the five questions are table stakes and the real work moves into the contract: what the renewal terms are, what happens to your data on termination, and whether there is any commitment on the compatibility cadence at all. Free apps sitting in critical paths are the thing to be genuinely nervous about, because a free app has no revenue funding its maintenance.
Run the same five questions against the apps already in your store, starting with anything that touches checkout, and you will usually surface two or three dependencies nobody has looked at since installation day. This is the higher yield exercise, because the vetting you skipped is already sitting in production.
Pull the list, sort it by how close each app sits to the money, and start at the top. Checkout, payments and subscriptions first. Fulfilment and inventory second. Everything decorative last. For each one, find the last release date and compare it against the current API version. That single comparison will do more for you than an afternoon of reading reviews, because it is the one signal a vendor cannot dress up.
Expect to find spend as well as risk. Our tech stack audit guide puts typical redundant tooling cost at $1M brands somewhere between $800 and $2,000 a month, alongside four to eight weekly hours of manual overhead created by tools that no longer talk to each other properly. Some of that is duplicate capability. Some of it is the residue of vendors who stopped shipping and were never removed.
None of this requires a project. It requires one calendar block per quarter and the willingness to uninstall something that still technically works. The discipline that keeps a stack healthy is not choosing better apps. It is being honest about which of the ones you already chose are still being maintained by somebody who has a reason to care.
Check the vendor’s public release history against Shopify’s API version schedule. Shopify ships a new API version every quarter and supports each stable version for a minimum of twelve months, so an app whose last release predates the current supported version is already drifting. Beyond the changelog, look at how many apps the vendor maintains and what they charge. Compatibility work is a recurring, non optional engineering cost that has to be funded from somewhere, and a large catalogue on very low pricing is the combination most likely to go quiet. Install counts are a reasonable proxy for whether that revenue exists, since they are harder to manipulate than review scores.
Often yes on headline cost, because most Magento extensions sell on a one time licence while Shopify apps bill monthly, but the comparison is incomplete without hosting and upgrade labour. On Magento you own the code and the infrastructure, which means you also own the security patching, the version upgrades across roughly three year release lines, and the developer time when an extension breaks. On Shopify the vendor absorbs all of that inside the subscription. The honest framing is that Magento shifts cost from a predictable monthly line into unpredictable engineering time. Whether that is cheaper depends entirely on whether you have the technical capacity to absorb it.
Built for Shopify means an app cleared Shopify’s thresholds for install counts, review volume, ratings, clean uninstalls and checkout performance impact at its most recent annual review. Developers get 60 days to fix failures, and repeated violations cost the status plus a three month reapplication ban. It is real governance and a useful first filter. What it does not tell you is whether the vendor has financial runway, whether they are about to be acquired, whether your renewal price is going up, or whether they still intend to maintain that particular app. Use the badge to shorten the list, then check the changelog yourself.
There is no correct number, but the useful benchmark is that the average Shopify merchant runs around six apps while scaling brands typically run fifteen to twenty five. The number that matters is not the count, it is how many of those apps sit in a revenue critical path and how many are still actively maintained. Ten well maintained apps, each doing one job, is a healthier stack than five abandoned ones. The failure mode at $500K to $2M is not app count in the abstract. It is accumulating dependencies faster than you accumulate the operational discipline to review them, which is usually about eighteen months of app by app decisions before anyone notices.
That depends on the app and you should establish it before you install, not after. Shopify requires apps to uninstall cleanly and to handle data deletion requests, but the configuration, historical records and any derived data living in the vendor’s own systems are governed by the vendor’s terms rather than Shopify’s. Subscription apps, reviews apps and loyalty apps are the ones where this bites hardest, because the accumulated history is the asset. Ask two questions before installing anything in that category: can you export your data in a usable format on demand, and what is the retention and deletion policy after termination. Get the answer in writing.
