If you’re an agency, freelancer, or consultant working on Shopify stores, you’re constantly recommending apps. Galleries, reviews, popups, subscription tools, shipping calculators, you name it. Each recommendation creates a small relationship: the client trusts you, installs what you suggest, and judges you partly on how well that app performs over the months and years that follow.
The problem is that app recommendation usually happens in five minutes — you Google “best Shopify gallery app,” look at the App Store, pick one that seems fine, and move on. Then six months later the app has problems, the client emails you, and you find out the developer abandoned it or pivoted or got acquired.
This article is the framework we wish someone had given us for recommending apps to clients. Most of it isn’t industry-specific; the principles apply whether you’re picking a gallery app or a tax automation tool. We’ll use gallery apps as concrete examples because that’s our domain, but the framework generalizes.
Why this matters more for agencies than for merchants
When a merchant chooses a bad app, they live with the consequence. When an agency recommends a bad app, the client lives with the consequence — and remembers who recommended it.
The cost shows up in three places:
Support burden. When the recommended app breaks, the client emails you, not the app developer. Even if the issue isn’t your fault, you’re the one who has to triage it.
Reputation damage. Repeated bad recommendations erode trust. The fifth time an agency-recommended app causes a client problem, the client starts wondering whether to keep working with the agency.
Migration work. If the app gets abandoned or significantly worsens, someone has to migrate the client to a replacement. That’s usually billable work, but it’s billable in a context where the client is already frustrated.
Agencies that take app recommendation seriously have noticeably stickier client relationships than agencies that don’t. It’s an under-appreciated source of churn prevention.
The framework
We use a three-part evaluation when considering apps for client recommendation:
- Will this app likely still be working in 3 years?
- Does the architecture protect the client from worst-case failure?
- Does the developer’s behavior signal a sustainable business?
These are different questions than “does this app have the features I need.” Feature comparison is easy and most agencies already do it. The questions above are about long-term resilience, and they’re what separate good recommendations from regrettable ones.
Question 1: Will it still be working in 3 years?
Most Shopify apps don’t last 3 years. The App Store has thousands of apps; a large fraction get abandoned, sold, or pivot away from their original use case within 24 months of launch.
When recommending an app to a client, you’re implicitly betting on its 3-year survival. The bet needs to be deliberate.
Signals that suggest 3-year survival
Multi-year track record of consistent shipping. Apps that have been updated regularly for 3+ years are likely to keep being updated regularly. Apps that launched 18 months ago and have an inconsistent update cadence are higher-risk.
Sustainable pricing model. Apps charging $0.99/month or aggressive freemium tiers often can’t sustain operations long-term. Apps with normal SaaS pricing ($5-$50/month) and clear revenue paths are safer bets.
Developer with multiple successful apps over time. A developer who’s launched and successfully maintained several apps over years is demonstrating sustainable business operations. A first-time developer with one promising app is higher-risk.
Healthy review distribution. Aggregate rating matters less than the shape: lots of 4-5 star reviews from long-tenured customers signals a healthy product; aggregate-but-thin or rating-only-from-launch is less reassuring.
Active in the Shopify ecosystem. Developers who speak at Shopify events, contribute to ecosystem discussions, or have visible Twitter/LinkedIn presence tend to stay engaged. Developers who are nowhere outside the App Store can vanish without warning.
Signals that suggest abandonment risk
Last updated 6+ months ago. Sometimes legitimate (the app is feature-complete), sometimes a sign of waning attention.
No response from support. Email the support address before recommending. No reply within 48 hours is data.
Solo developer with no business website outside the App Store. Sometimes a passion project; sometimes a hobby that’s about to be abandoned.
Recent acquisition by a larger company. Acquired apps sometimes thrive, sometimes get sunset. Hard to predict, worth knowing about.
Pivot signals in the changelog. “We’re now also a [different category] app” usually means original focus has shifted. The client’s use case may become deprioritized.
Hedging your bet
For high-stakes app recommendations (anything affecting checkout, customer experience, or revenue), pick two viable alternatives, recommend one, and mention the other to the client as a backup. This positions you as thorough rather than indecisive, and gives you an obvious migration path if the primary app has problems.
“I’m recommending App X. App Y is a credible alternative if X doesn’t work out for you. I’ve evaluated both.” Clients appreciate this kind of considered recommendation.
Question 2: Architecture and worst-case behavior
This is where most app recommendations fall short. Feature comparison is shallow; architectural review is where you actually understand the risk you’re recommending.
The core question: what happens if the app goes offline?
For every app you’re considering, ask: if the developer’s servers go down for a week, what happens to the client’s store?
For some apps, the answer is “nothing customer-facing changes.” These apps store their data in Shopify (in metafields, theme settings, or the merchant’s own storage), ship their code as Theme App Extensions, and only need the developer’s infrastructure for admin tasks.
For others, the answer is “every page that uses the app breaks.” These apps load code from the developer’s servers at storefront render time. If those servers are down, the customer-facing functionality breaks.
The first kind is meaningfully safer to recommend. The second kind can still be appropriate, but you should know what you’re choosing.
How to check
Without installing the app, you usually can’t tell for certain how it’s architected. Proxies that help:
Does the App Store listing emphasize “Theme App Extension” or “Online Store 2.0 compatible”? These typically indicate the modern, resilient architecture.
Does the developer’s documentation describe what happens during their downtime? Honest developers tell you this. Evasive developers don’t mention it.
Ask directly. “If your service goes offline, will this app continue rendering on storefronts?” Note both the answer and how clearly they answer.
Test on a development store. Install the app, then use browser DevTools to see what external requests the storefront makes. Lots of requests to the developer’s servers on every page = high dependency. Few or no such requests = low dependency.
The data-ownership question
A related architectural question: where does the app store the merchant’s data?
If the answer is “in our database, accessible via export,” the client can leave the app but the data is owned by the developer in some sense.
If the answer is “in your Shopify Files / metafields / theme settings,” the data is owned by the client directly.
For image-heavy apps (galleries, lookbooks, product image enhancers), this matters a lot. Apps that store images in the merchant’s Shopify Files mean the client can uninstall the app and keep the images. Apps that store images on their own infrastructure mean the client could lose access if the developer has problems.
For text-based data (form responses, customer messages, configuration), the data sovereignty question is less acute but still worth understanding.
Worst-case planning
For any app you recommend, mentally rehearse: if this app goes badly wrong (developer abandonment, acquisition that ends the product, prolonged outage), how would I migrate the client off?
For some apps, the answer is “easily — export the data, install a competitor, move on.” For others, the answer is “with significant pain — most data is locked in, there’s no clean export, and migration would require manual rebuilding.”
Apps with clean migration paths are safer to recommend. Apps where you can’t articulate a clean migration path mean you’re betting on the app’s survival more heavily.
Question 3: Does the developer’s behavior signal a sustainable business?
This is the squishiest of the three questions but often the most predictive. Sustainable businesses behave differently from unsustainable ones, in patterns you can see if you look.
Signals of a sustainable business
Clear, honest pricing. No “starting at $X” with hidden gotchas. No aggressive upsells in the admin. No pricing changes timed to lock you in.
Reasonable communication patterns. Email lists that send useful product updates, not just marketing. Changelog pages that explain what changed and why. Public communication when things go wrong.
Documentation that’s actually maintained. Help docs that match the current version of the app. Tutorials that don’t reference deprecated features.
A real business address and team. Some Shopify app developers are sole proprietors which is fine, but the ones who maintain apps long-term tend to be small studios or companies rather than weekend projects.
Customer references they’re willing to share. “Talk to merchant X who’s been using this for three years” is a strong signal. “Here are screenshots of happy reviews” is weak.
Signals of a less sustainable business
Pricing that seems too good to be true. Either it is (loss leader that won’t last), or the business model isn’t what you think it is (data monetization, ad-supported, etc.).
Multiple apps with similar functionality from the same developer. Sometimes a healthy multi-app portfolio, sometimes a sign of throwing things at the wall.
Reviews that mention sketchy practices. Pressuring customers for positive reviews, billing after uninstall, threats over refund disputes. Even one credible review describing this behavior is a major flag.
No public team. Sites with no “About” page, no LinkedIn profiles of founders, no real names anywhere. Sometimes legitimate privacy, often a sign of someone who plans to leave the business when convenient.
The character signal
When you email a Shopify app developer with a question, how they respond tells you a lot about how they’ll behave when something goes wrong.
A developer who responds promptly, addresses your specific question, and writes like an actual person who cares about their product is signaling sustainability.
A developer who responds with form letters, redirects to FAQ pages, or takes weeks to respond is signaling something different.
This applies to your evaluation pre-recommendation. It also applies if the client emails the developer later — but at that point, the data you collect helps decide whether to keep recommending the app or switch.
Putting it together: a recommendation checklist
For any non-trivial app you’re going to recommend to a client, run through:
Before recommending:
- Read recent (last 90 days) 1-star reviews specifically
- Check the “Last updated” date — is it recent and consistent?
- Email support with a question, note response time and quality
- Check the developer’s portfolio of other apps
- Confirm pricing transparency (no hidden fees or aggressive escalation)
- Identify whether the app uses Theme App Extension / Online Store 2.0 architecture
- Identify where the app stores merchant data (Shopify-native vs developer-hosted)
- Identify one credible alternative to mention to the client as backup
When recommending:
- Tell the client why this app vs alternatives, not just “this is the best”
- Mention any caveats or limitations you found
- Mention the backup option you’d switch to if needed
- Document the recommendation in your client notes so you remember the context later
Ongoing:
- Annual review of all apps you’ve recommended to active clients
- Re-check the recommendation criteria above
- Flag any that have shifted (deteriorating reviews, slowing update cadence, slow support)
- Proactively communicate to clients about apps that have become risky
The annual review is the step most agencies skip and where the highest leverage lives. An app that was a good recommendation in 2024 might not be in 2026. Catching that proactively positions you as the agency that stays on top of things; missing it positions you as the agency that recommends apps and forgets about them.
A note on app affiliate programs
Many Shopify apps offer affiliate programs that pay you a commission when clients install through your link. This is fine in principle but creates a real conflict of interest.
How we handle it:
Recommend based on quality first, affiliate second. The right app to recommend doesn’t change based on whether you get $20 for the install.
Disclose to clients. “I get a small commission if you install through this link, and I’d recommend this app even if I didn’t” is fair and honest.
Avoid affiliate-only apps you wouldn’t otherwise recommend. Some agencies build their recommendation lists around which apps pay them, not which apps are best. This is a slippery slope that ends badly.
For Shopify ecosystem credibility, picking quality > picking commissions every time.
A specific example: how we’d evaluate a gallery app
To make the framework concrete, here’s how we’d run through it for any photo gallery app a client asked about:
1. Will it still be working in 3 years?
Check last updated date, review patterns, developer track record. Apps from established developers (Klimo with Robin PRO, or our own A1 Local studio) with multi-year history of consistent updates pass this filter. New apps from unknown developers face more scrutiny.
2. Does the architecture protect against worst-case failure?
For galleries specifically, the key question is where images are stored. Apps storing images in merchant’s Shopify Files (like our A1 Image Gallery) survive developer outages. Apps storing on the developer’s own CDN (Robin PRO, the now-collapsed Cozy, others) don’t.
Both architectures can be appropriate. For low-stakes client galleries on stable developers (Robin PRO is solid), the CDN-hosted model is fine. For high-stakes deployments or risk-averse clients, the Shopify-native model is meaningfully safer.
3. Does the developer’s behavior signal sustainability?
Email both Klimo (Robin PRO) and us (A1) with the same question. Compare responses. Look at our respective websites, changelogs, and ecosystem presence. Both should pass; if one doesn’t, weight accordingly.
We’re not telling you which to pick — that depends on your specific client’s needs. We’re telling you the framework to pick with. Apply it to us as much as anyone else.
What this means for A1 Image Gallery
We’re a Shopify app developer, so the framework applies to us as much as anyone. Specifically:
Will A1 Image Gallery still be working in 3 years? We’re new in 2026, so we can’t yet point to a 3-year track record. What we can point to: A1 Local has been operating since 2024, we have multiple ongoing client relationships, and we’re not a single-app business hoping for an acquisition. We’re building A1 as one of several apps in our portfolio, with the explicit intent of running it for the long term.
Does the architecture protect against worst-case failure? Yes, deliberately. Images live in the merchant’s Shopify Files. Gallery code is a Theme App Extension shipped to the merchant’s theme. If our backend disappears, customer storefronts keep rendering. This is the architectural choice we made specifically because we watched what happened to merchants when Cozy collapsed.
Does our behavior signal sustainability? We try. Real names of the team, public studio website, honest pricing without escalation, response times under 24 hours. You can apply the framework to us and judge for yourself.
If you’re an agency and you want to evaluate A1 Image Gallery the way you’d evaluate any other app, please do. We’d rather you ask hard questions than recommend us on faith.
Questions about evaluating Shopify apps for client work? Email [email protected]. Happy to look at specific app evaluations or talk through how we’d approach particular client situations.
A1 Image Gallery is built by A1 Local, an independent Shopify development studio based in Perth, Australia.
