When is a public Shopify app enough and when does a custom Shopify app pay off? A guide to the decision, the build phases, realistic timelines, running costs, ownership and data.
Every growing Shopify store hits the same fork. A workflow is being done by hand, or with three apps taped together, and someone asks whether it would be better to build something. The honest answer is that it depends, but it depends on things that can be named. This guide names them: when a public app is enough, when a custom app pays for itself, what the build actually involves, how long it takes, what it costs to run, and who ends up owning what.
The decision in one sentence
Buy when your problem is common and the app solves it the way you would; build when your problem is specific to how your business works, or when the apps you are stacking cost more in fees, load time and workarounds than a purpose-built tool would. Everything below is detail on that sentence.
When a public app is enough
The Shopify App Store exists because most store problems are shared. Reviews, subscriptions, bundles, wishlists, back-in-stock alerts, shipping rules, collection sorting: for each there are mature apps that have already absorbed years of edge cases you have not met yet. If a public app does what you need in the way you need it, it is almost always the right choice.
- The workflow is standard and the app's opinion about it matches yours.
- You need it working this week, not this quarter.
- The monthly fee is small relative to the value, and stays small as you grow.
- The app is actively maintained and the developer responds to support.
- You can leave: your data, or at least the outcome of the app's work, stays in Shopify if you uninstall.
That last point deserves attention. Apps that write their results into Shopify itself, such as a sorting app that sets the manual sort order, or a tagging app that writes real tags, leave you with the outcome even if you leave the app. Apps that keep the value inside their own dashboard are harder to walk away from. We built SellRank at LeelaRam Technologies to write into Shopify's own sort for exactly this reason: the order stays even if the subscription does not.
When custom starts to pay off
Custom makes sense when the gap between what apps do and what you need is costing you every day. The common triggers, in our experience:
- A process specific to your business, such as a made-to-order workflow, a pricing rule tied to a commodity rate, or an approval step between order and fulfilment, that no public app models.
- An integration with a system that is yours: an ERP, a warehouse, an accounting package configured your way, a supplier's portal.
- An app stack where you are paying for five apps and using a fraction of each, with scripts from all five slowing the storefront.
- A public app that does most of the job but whose one missing feature forces manual work on every order.
- Data you want to own and analyse in your own way, rather than through an app's reporting screen.
The signal is usually a person. If someone on your team spends hours a week doing something a computer should do, and the reason is that no app quite fits, you have found the candidate.
Off-the-shelf has hidden costs that only show up in aggregate. Subscriptions stack until the monthly app bill rivals the Shopify plan itself. Each storefront app adds its own script, and the sum of them is often why a store fails Core Web Vitals. Workflows get bent to fit the app's model rather than the business's, and the bend is absorbed by a person doing workarounds. None of these appear on any single app's pricing page, which is why the stack should be reviewed as a whole at least once a year.
What a custom app actually involves
A custom Shopify app is a small hosted service. It authenticates with your store, reads and writes through the Admin API, reacts to webhooks when orders or products change, and may add pieces to the storefront or the admin through extensions. Understanding the phases helps you judge quotes and timelines.
- Discovery: writing down the problem, the workflow as it is today, the data involved and what done looks like. A week or two, and the cheapest place to find out that the problem is different from what everyone assumed.
- Design: the data model, the Shopify APIs and webhooks involved, the screens if any, and the failure cases. Often folded into discovery for a small app.
- Build: the app itself, with automated tests for the logic that touches money or inventory.
- Launch: installing on the live store, running against real data with a rollback plan, and monitoring from day one.
- Run: API version upgrades, small changes as the business changes, and someone watching the alerts.
Realistic timelines
Timelines depend on scope far more than on the platform, but some patterns hold. A single-purpose custom app for one store, with one workflow and no user interface beyond a settings page, is typically a matter of weeks from discovery to running in production. An app with a real admin interface, several workflows and integrations to outside systems is a matter of months. A public app destined for the App Store adds billing, onboarding for strangers, listing review and support, which extends the timeline and, more importantly, the ongoing commitment.
The number that matters more than the calendar is time to first evidence. A good partner puts a working slice into your live store early, so that you can see it handling real orders before the larger investment is made. If a proposal has nothing running until the end, ask why.
What it costs, and what it costs to run
Build cost is driven by scope, by the number of systems the app touches, and by how much of the work is interface versus logic. Interfaces are expensive; a job that runs on a schedule and writes results into Shopify is cheap by comparison. The most reliable way to control cost is to cut scope to the smallest version that removes the manual work, ship it, and extend it once it has proved itself.
Running costs are the part people forget. A custom app needs hosting, which for a single-store app is modest but not zero; a database; monitoring; and, most importantly, maintenance. Shopify releases a new API version every quarter and each version is supported for a fixed period, so an app that nobody touches will eventually stop working. Budget for someone to spend a small amount of time on it each quarter. Compare the total, build plus running costs over two or three years, against the same period of app subscriptions plus the cost of the manual work those apps do not remove. That comparison, in INR and in hours, is the honest one.
Ownership and data
With a public app, you own a subscription. The app's code, its infrastructure and usually its data belong to the developer, and the terms can change. With a custom app built properly, you own the source, the hosting accounts, the data and the right to change any of it. That ownership only exists if the contract says so and the accounts are in your name from day one, so check both before signing.
- The code should live in a repository you own, with the partner added as a contributor.
- Hosting, domain and any third-party services should be on your accounts and billed to you.
- Customer data the app stores should be documented: what, where, for how long, and how it is deleted, which matters under India's data protection law as well as Shopify's requirements.
- The app should be installable by a different developer from the documentation alone.
The middle path most stores actually take
Build versus buy is rarely all-or-nothing. The pattern that works for most growing stores is to use mature public apps for the common problems, and to build one small custom app for the workflow that is genuinely theirs, usually the one that touches their own operations or an outside system. Keep the custom scope narrow, keep the public apps to the few that earn their fee, and revisit the split once a year as the business changes.
There is also a smaller step between the two. Shopify Flow handles a surprising amount of automation without any code, and a public app that exposes an API or webhooks can often be extended with a few hundred lines of custom code rather than replaced. Before commissioning a full app, ask whether the missing piece is a whole product or just a bridge between two things you already pay for. Bridges are cheap, fast and easy to maintain.
A useful test before committing to either: write the workflow down in plain language, step by step, and put it next to the app listing or the proposal. Whichever one covers the steps without a workaround is the answer. If neither does, the problem needs a clearer definition before it needs software.
