The only honest way to decide whether to build a custom Shopify app is arithmetic. Count the minutes a task eats each week, multiply by the loaded cost of the person doing it, add the cost of the mistakes they make when they're tired at 11pm during a festive sale, and compare that to build cost plus about 15–20% a year in maintenance. If the payback is under twelve months, build it. If it's three years, don't. Most of the app ideas founders bring us fail that test, and saying so is cheaper for everyone than a proposal.
But the ones that pass tend to pass enormously. Custom Shopify apps earn their keep on tasks that are boring, daily, high-volume and rule-based, where a human adds nothing except the risk of typing 5,340 instead of 5,430.
Where the hours actually disappear
When we shadow an operations team for a day before scoping anything, the same jobs show up across very different stores:
- Retyping prices every morning because a raw material, a metal rate or a supplier list moved overnight.
- Confirming COD orders one by one on WhatsApp or by phone, then cancelling the ones nobody answers.
- Copying orders into a courier panel, then copying AWB numbers back into Shopify so customers get a tracking link.
- Reconciling Razorpay settlements against Shopify orders in a spreadsheet, because the payout is net of fees and lands in batches.
- Tagging orders by hand so the warehouse knows what's a gift, what's fragile, what ships from which location.
- Editing metafields across a few hundred SKUs because marketing changed a badge rule.
- Keying B2B or distributor prices into a second, parallel price list.
None of that is strategy. It's transcription. And transcription is exactly what an app does without complaining.
Try Shopify Flow and a spreadsheet before you write a line of code
Here's the unwelcome bit. A good share of the automation founders ask us to build already exists, either in Shopify Flow or in a ₹500-a-month app on the App Store. Order tagging, inventory alerts, fraud holds, customer segmentation triggers, cancelling unpaid orders after N hours — Flow handles all of it, and it's free on Basic and above now. Marketplace sync, COD verification and courier integrations have mature third-party options built by teams who do nothing else.
We tell clients to exhaust that layer first. Not because we don't want the work, but because a client who pays us three lakh for something Flow does in eight steps will find out eventually, and that's the end of the relationship. Custom development should be the second answer, not the first.
What Flow can't do is the interesting part. It can't call an external API and do arithmetic on the response. It can't render a screen inside Shopify admin for your merchandiser. It can't handle a rule with fifteen conditions and a lookup table. It can't reprice 4,000 variants in one shot without hitting rate limits. That's where custom Shopify apps stop being a luxury.
A worked example: daily repricing
Take a jewellery store, because it's the cleanest case we see. Gold moves every day. Every product's price is a function of weight, purity, making charge, wastage and GST. If you have 900 live SKUs and someone updates them from a rate sheet each morning, that's an hour of work minimum, and it's an hour where a single fat-finger error sells a 22K chain at 18K pricing.
Run the numbers. One hour a day, six days a week, is 26 hours a month. At a loaded cost of ₹400 an hour that's ₹10,400 a month, or ₹1.25 lakh a year, to do something a script does in four seconds. Then add the errors. One mispriced ₹85,000 bangle sold at a 9% discount by accident is ₹7,650 gone, and it happens more than once a year.
The other half of the problem is on the storefront. Customers in this category want to see the live rate and the breakup, not a flat number they can't verify. That's a display problem plus a repricing problem, and it's common enough that we packaged it as Gold & Silver Live Rate rather than rebuilding it per client. If your requirement is exactly that, buy it. If your requirement has a wrinkle — a distributor rate card, a per-branch making charge, a franchisee approval step before a price goes live — that wrinkle is what a custom build is for.
A worked example: COD confirmation
Say you ship 3,000 COD orders a month and someone on your team confirms each one. At 90 seconds per order including the ones that don't pick up, that's 75 hours a month. Two people, most of their day, on the phone.
An app that fires a WhatsApp confirmation on order creation, tags the order on reply, holds it for 12 hours, and auto-cancels or converts to prepaid-only if there's no response takes that 75 hours to near zero, plus maybe five hours of exception handling. Then the second-order effect, which is bigger. Use your own RTO number here, not one from a blog post. If your unconfirmed COD RTO is 25%, that's 750 returns a month. At ₹120 in forward plus reverse freight, you're spending ₹90,000 a month to move boxes in a circle. Shave that rate by five percentage points and you've saved 150 returns, ₹18,000 in freight, and the working capital those units were sitting in.
We build this pattern often, and we still start by asking whether an existing COD verification app covers it. Sometimes it does. It stops covering it the moment you want the decision to depend on pincode risk, order value, customer order history and whether the item is a final-sale SKU — because that logic is yours, and no off-the-shelf app knows your return data.
Custom apps also fix the jobs nobody admits to
The unglamorous internal app is often the highest-return thing we build. A single admin page that lets a merchandiser bulk-edit 300 metafields from a CSV. A screen that shows the warehouse a picking list grouped by shelf rather than by order. A nightly job that pulls yesterday's Razorpay settlement report, matches it against orders, and flags the ones that don't reconcile so finance looks at eleven rows instead of eleven hundred.
These never get built because they're not marketing, so they never win the budget fight. They also have the shortest payback of anything on the roadmap. A reconciliation job that saves a finance executive two days a month at month-end pays for itself in a quarter.
What a build actually costs and how long it takes
A narrow, single-purpose internal app — one trigger, one action, no UI beyond a settings page — is a two to three week build for one developer. Something with an embedded admin interface, a background job queue and an external API integration is six to ten weeks and needs a second pair of hands for QA. Our commercial ranges sit on the Shopify development cost page, and they're ranges for a reason: the same brief costs twice as much when the external system you're integrating with has no sandbox.
Budget for the parts founders forget:
- Hosting. A custom app is your software running on your infrastructure. Small ones run on a modest node for a few thousand rupees a month. Ones that process webhooks at festive volume don't.
- API version churn. Shopify ships a new Admin API version quarterly and supports each for about a year. Something in your app will break on a version bump roughly once a year. Plan a maintenance retainer or plan a fire.
- Rate limits. On non-Plus plans the REST call bucket refills at two requests a second. Repricing 4,000 variants naively takes half an hour and gets throttled. Written properly against the GraphQL bulk operations endpoint, it's minutes. This is the single most common reason a cheap build performs badly.
Where these builds go wrong
Multiple locations. Almost every automation we write breaks the first time a client adds a second warehouse, because the original spec assumed one inventory pool and nobody said so out loud. We now ask about locations in the first call and we still get it wrong on the first pass sometimes.
Then there's the human bypass. If the app auto-tags orders but a staff member can still edit the tag manually in admin, someone will, and your downstream logic will silently do the wrong thing for three weeks. Either lock the field or build a reconciliation report that catches drift.
And webhooks are not guaranteed exactly once. Shopify retries. If your app increments a counter or issues a refund on orders/paid without an idempotency key, you'll eventually do it twice. Ask whoever quotes you how they handle duplicate webhook delivery. The answer tells you a lot.
How to scope one in a week
Before writing any spec, have the person doing the task keep a log for five working days: what they did, how long it took, how many rows or orders. Not a memory-based estimate. An actual log. Two things fall out of it. Half the tasks turn out to be smaller than everyone believed, and one task nobody mentioned turns out to be eating nine hours a week.
Then split the list three ways: Flow can do it, an existing app can do it, only code can do it. Build the third column, starting with whichever item has the worst hours-to-complexity ratio. If you need hands for that, our Shopify app development team scopes exactly this way, and for smaller pieces it's often cheaper to hire a Shopify developer on a monthly basis than to run a fixed-bid project with change requests.
Start with the five-day log. If it shows more than ten hours a week of pure transcription, send us the log and we'll tell you which rows are worth automating and which ones aren't — the audit is free and the honest answer is sometimes "use Flow".