App, theme app, or custom app: how to decide

Most of the questions I get asked start the same way — “we need an app that does X” — and most of the time the right answer is “there is an app that does X and you should install it today.” The expensive mistake is not failing to build something. It is building something that already existed.

So here is the decision, in the order I would actually make it.

Start here: does a general app already do this?

Search the App Store for the problem, not the solution. Search “inventory sync” rather than the name of an app you saw somewhere. Read the reviews, and read the recent ones — a listing with 400 reviews where the newest is from eight months ago is a different product from one with 400 where the newest is last week.

If something does what you need, install it. This is the common case and it is not the boring case. A good app is months of work you get for the price of a subscription, and the maintenance is somebody else’s scheduled problem rather than yours.

Stop here if the app does what you need. Everything below is for when it doesn’t.

Theme app: only when the problem lives in the theme

A theme app injects into your storefront. Liquid, sections, blocks, the product page, the cart, the theme editor. That is the whole surface.

It is the right tool when:

The thing you want to change is what a customer sees or does on the front end
It needs no access to orders, inventory, or customer records
It should follow the theme — if the merchant switches themes, the app goes with it
It is genuinely visual: a bundle picker, a size guide, a subscription widget

It is the wrong tool the moment anyone says “and it should also update the order when” or “and it needs to know the stock level.” Theme apps are sandboxed away from data precisely so a theme editor cannot read your customer list. That sandbox is a feature, and it is also the wall you will hit.

The failure I see most often: a merchant asks a theme app author for a feature that requires server-side work, and the honest answer is “that is a real app, not a theme app.” Both are valid products. They are not interchangeable.

Custom app: when the work is core to how you operate

Now the expensive branch. A custom app is worth it when the process is differentiated, not merely inconvenient. The test is not “is this hard?” — plenty of hard things are worth an off-the-shelf app. The test is:

Would a competitor running the same operational process be better off if they did what you do?

If the answer is no, and the process is just how you happen to work, an app with a flexible configuration is cheaper and you should configure it.

If the answer is yes, a custom app starts to make sense, because what you are paying for is the specific way your business operates. The app encodes a decision you have already made, and it saves everyone who works there from remaking it.

Good candidates, from real shops:

Inventory rules that encode your warehouse’s actual behaviour. Not “sync stock” — the precedence between locations, the buffer logic, what happens when two systems disagree. Every business has this and no two are the same.
B2B pricing that your finance team will actually accept. Order minimums, tier breaks, contract pricing, net terms, a purchase-order flow. Off-the-shelf apps cover maybe 80% of this and the last 20% is the part your invoicing process depends on.
A feed that leaves for a destination that expects a specific shape. Most feed apps do a good general job. The ones that don’t are the ones feeding a partner with a rigid contract.

What custom actually costs

The number that surprises people is that it is rarely the build. It is everything that arrives after the build.


The build	The part you budget for
The API versions	Scheduled work, four times a year, forever
The Shopify review	Required for anything touching customer or order data
The edge cases	The support tickets about what happens when two things happen at once
The handover	The documentation nobody asked for and everyone needs
The exit	The day you stop using it, and what happens to your data

That last row is the one that gets skipped in scoping. Build something and there is no vendor to leave — no API to revoke, no rate limits to renegotiate, no price increase to absorb. You own the code and the data, which is a genuine benefit, and it is also genuinely more work. It is a trade, and it should be made knowingly.

A note on the middle path

There is a fourth option that gets skipped because it sounds like a compromise, and it very often is the best one: an existing app, configured hard, plus a small custom piece for the part it cannot reach.

Most of the “we need something custom” conversations I have end here. The merchant wanted certainty on one specific step, not a new system. Configure the app for everything it handles, build only the gap, and you get most of the benefit for a fraction of the cost and surface area.

The gap is where the custom piece goes. The reason it works is that it is small enough to reason about completely — which is the only property that makes custom work safe.

How to tell which one you are

Three questions, in order. Stop at the first yes.

Does an app already do this? → install it.
Is this purely what the customer sees on the storefront? → theme app.
Does this encode how we operate, and would a competitor want it? → custom app, or the middle path above.

If you get to the third question and the honest answer is “we are just trying some things out,” wait. Most custom apps should be the third thing someone builds, not the first.

If you have been through all three and landed on “custom,” that is a real answer and not a failure — it just means the process is core enough to be worth owning. Send me what you are trying to do and I will tell you honestly whether it is a build, a configuration, or a thing you should wait six months on.

I would rather tell you to wait than take a project that should have been a setting.