When a Custom Shopify App Is Worth Building

There is a spreadsheet somewhere in your business that should not exist.

Somebody opens it every morning. It reconciles something Shopify does not track, or applies a pricing rule the platform cannot express, or holds the state of a process that spans three systems none of which agree with each other. It has a tab nobody understands and a formula that broke once and got patched with a hardcoded value.

That spreadsheet is usually the first honest sign that a custom app might be worth building. It is not proof — plenty of spreadsheets are fine, and plenty of others are a symptom of a process problem no software will fix. But it is the right place to start asking.

The three options before you build anything

Almost every requirement that arrives described as "we need a custom app" has three possible answers, and custom development is the most expensive of them. Work through the cheaper ones honestly first.

The mistake is not choosing custom. It is choosing custom without having genuinely tested the other two — usually because someone tried one app, found it imperfect, and concluded the category was hopeless.

Five questions that decide it

1. Is the rule specific to your business, or common with a twist?

This is the highest-signal question. If ten other merchants in your category need the same thing, an app almost certainly exists, and it will be cheaper and better-tested than anything built once. If the rule encodes something particular to how you trade — a pricing structure negotiated per account, a fulfilment sequence driven by your own warehouse constraints, an approval step your industry requires — no vendor is going to model it for you.

Be honest about "with a twist". A common requirement with one unusual detail is often better served by an app plus a small integration than by rebuilding the whole thing to accommodate the detail.

2. Has the process stopped changing?

Code is a poor place to store a rule that is still being argued about. If the finance team is mid-way through revising how discounts are approved, building the current version means building something that will be wrong before it ships.

Wait until the process is boring. Boring is the signal that it is ready to be automated.

3. What happens when it breaks?

Every custom app eventually fails at an inconvenient moment. An API times out, a payload arrives malformed, a webhook fires twice. The question is what the business does next.

If the answer is "we would not notice for a day", you need alerting designed in from the start, not added later. If the answer is "orders stop", you need retries, idempotency, and a manual fallback path. If the answer is "we would call the agency and hope", that is an ownership problem to resolve before you build, not after.

4. Who owns it in two years?

The build is a project. The app is a permanent obligation. Somebody has to keep it running as Shopify's API versions move forward, as your business rules change, and as the people who commissioned it move on.

That does not mean you need an in-house developer. It means you need a named arrangement — an internal owner, a support retainer, or documentation good enough that a new team can pick it up. What does not work is assuming it will look after itself.

5. Can Shopify actually do this?

Some requirements are not available at any budget. Checkout is the usual place teams discover this. Shopify governs what can be changed there, and while checkout UI extensions and Functions cover a real set of use cases, they cover a defined set. Availability also depends on your plan.

Confirm feasibility during discovery, before scope is agreed. Finding out mid-build that the central requirement is not permitted is the worst possible time.

What a custom app actually costs to own

The build quote is the number everyone focuses on. It is rarely the number that matters most.

Hosting. An embedded app needs a backend running somewhere. For most operational apps this is not a large bill, but it is a permanent one, and it belongs to you rather than being bundled into an agency invoice.

Monitoring. An app that fails silently is worse than no app, because the business keeps trusting data that stopped updating. Alerting is not optional, and someone has to be on the receiving end of it.

API version upkeep. Shopify's API moves forward on a published schedule. Apps need periodic updates to stay current. This is modest, predictable work — but it is not zero, and an app left untouched for two years will eventually need attention all at once.

Change. The rule you encode today will be revised. Every revision is a small development task.

None of this argues against building. It argues for going in with the full picture, so the decision is made against real numbers rather than the build quote alone.

Custom app or public app

These are different products with different economics, and conflating them causes trouble.

A custom app is installed on your store, needs no App Store listing, and skips Shopify's review process entirely. It can be as narrow as you like. It exists to serve your operation.

A public app is distributed to other merchants. It must meet Shopify's review requirements, needs a billing model, a support function, documentation, and a roadmap. It is a software business, not an internal tool.

Teams occasionally start with "we'll build it for ourselves and sell it later". That is possible, but the two goals pull architecture in different directions — multi-tenancy, per-merchant configuration, and onboarding all have to be designed in early or retrofitted expensively. Decide which one you are building before you start.

Where custom apps most often pay off

Across the work we do, the requirements that genuinely justify custom development cluster into four areas. If yours does not resemble one of these, it is worth re-testing the cheaper options.

Pricing and quoting logic

Shopify's native pricing handles a wide range of ordinary cases well. Where it stops is when price depends on something the platform does not model: a customer's negotiated tier combined with order volume, a configuration priced from dimensions, a surcharge that applies only to certain postcodes, or a quote that needs approval before it becomes an order.

These are worth building because the rule is genuinely yours and getting it wrong costs margin on every transaction. They are also worth building carefully, because pricing bugs are the kind customers notice and remember.

Fulfilment and inventory rules

If stock allocation follows rules specific to your operation — reserving inventory for a channel, splitting orders across warehouses by proximity, holding items until a full set is available, or routing by supplier lead time — that logic has to live somewhere. When it lives in a spreadsheet and somebody's memory, it fails on the day that person is on holiday.

Customer account experiences

The default account area is deliberately minimal. Businesses with subscriptions, trade accounts, service histories, reorder patterns, or documentation to distribute often need something more substantial. This is a common driver of custom work, because the account area is where retention actually happens and the stock experience rarely reflects the relationship.

Internal operations tooling

The least glamorous category and frequently the highest return. An embedded admin app that removes a daily manual reconciliation is not exciting, but it saves the same hours every week and it removes a class of human error entirely. These builds tend to be small, well-defined, and quick to pay back.

What to prepare before a discovery call

Whether you build with us or anyone else, the quality of the first conversation determines how accurate the scope is. Turning up with these ready changes the outcome:

1. A written description of the current process, end to end, including the steps people do by hand and the exceptions they handle without thinking about them
2. The volume — how often it happens, how long it takes, and how often it goes wrong
3. The rules, stated explicitly, including the edge cases and who has authority to approve them
4. A list of the systems involved, who owns each one, and whether they have an API
5. What you have already tried — which apps were evaluated and why they were rejected, which saves everyone repeating the search
6. Who will own the result after launch

The item that most often derails scoping is the fourth one. A workflow that looks like a Shopify problem frequently turns out to depend on a system nobody mentioned, and discovering that after the estimate is how projects slip.

Signs you should not build yet

• The process is contested. Two departments disagree about the rule. Software will not settle that argument; it will encode one side of it.
• Nobody can describe the current workflow end to end. If it cannot be written down, it cannot be built correctly.
• The requirement is really a reporting need. A surprising number of "we need an app" conversations resolve into "we need to see this data in one place", which is often a dashboard or an export.
• The volume does not justify it. Automating a task that happens four times a month, takes ten minutes, and rarely goes wrong is a hobby project.
• There is no owner. If nobody will be responsible for it after launch, you are commissioning future technical debt.

How to scope one so it does not sprawl

When custom is the right answer, the failure mode shifts from "should we build this" to "why is this still going".

Build the smallest thing that removes the pain. Not the platform. Not the flexible system that handles every future case. The specific thing that stops the daily manual work. You can extend something that works; you cannot easily rescue something that was over-designed from the start.

Put it where the work already happens. An embedded app inside the Shopify admin gets used. A separate tool with its own login gets forgotten, and the spreadsheet quietly comes back.

Design for the failure cases first. Retries with backoff, idempotent processing so an event handled twice is harmless, and a queue for events that cannot succeed. This is unglamorous and it is what separates an app that survives contact with production from one that needs babysitting.

Ask for the narrowest API scopes. Request only the permissions the app genuinely needs. It reduces blast radius, and it forces clarity about what the app actually does.

Insist on handover documentation. Architecture, environments, deploy steps, and what each alert means. If the only person who understands it is the person who built it, you have bought a dependency rather than an asset.

The test, in one sentence

Build a custom Shopify app when a settled, business-specific rule is costing real operational time, no existing app models it without heavy workarounds, the platform permits what you need, and someone will own it afterwards.

If any of those four is missing, the honest answer is usually to fix that first.

If you are weighing this up for a specific workflow and want a second opinion on whether it needs custom development at all, describe the problem to us. We will tell you when an app from the store would do the job — it is a shorter conversation, but it is the right one more often than people expect.