App or custom build on Shopify: how to actually decide

Most Shopify development decisions follow a simple rule: if there's a good app for it, use the app. It's faster, cheaper upfront, and someone else maintains it. For the vast majority of features, that's the right call.

But the rule breaks down in specific situations. And the way to see those situations clearly is to work through a real case, not a framework.

The case: gift with purchase across two stores

A client wanted a gift-with-purchase feature. Spend over a certain amount, get a free product added to your cart automatically. Common mechanic, well-served by apps. BOGOS, Gift Box, and others handle this out of the box for around $20-50 a month.

On paper, the app was the obvious answer. In practice, a few things changed the calculation:

1. Fixed monthly retainer: The client had a fixed monthly retainer with us. Development hours were already paid. Building the feature ourselves meant a one-time investment of hours that were already budgeted, with no recurring cost added to their bill.
2. Multistore independent control: This client ran separate Shopify stores for Argentina and internationally. They wanted the same feature on both, but with independent control: sometimes the gift promotion runs in Argentina but not internationally, sometimes the reverse, sometimes with different products or different spend thresholds.

With an app, that means two separate subscriptions. And configuring each store independently through an app UI is manageable but adds operational overhead every time marketing wants to change something. With a custom build, both stores run the same codebase. Changes are fast, the logic is identical, and there's no per-store cost.

The math was simple. The retainer covered the build. The alternative was two monthly app subscriptions indefinitely, with less flexibility and a UI the development team didn't control.

How I built it

The gift product exists in Shopify as a real product, but I removed it from all sales channels so customers can't find or buy it directly. Shopify's native seo_hidden metafield keeps it out of search results. I reference it by variant ID in the code, not by handle, because handles can change for SEO reasons and silently break the logic.

The business rules live in the theme: check the cart against the configured conditions, add or remove the gift product via the Cart API, and render the appropriate UI. Progress bar showing how far the customer is from qualifying, a banner when the gift is added, confirmation in the cart.

A Checkout Extension handles the display at checkout, showing the gift item in the order summary with the right styling. I set up a Shopify Flow to tag qualifying orders for internal tracking. The order confirmation email got custom Liquid to detect the gift and include it in the email summary.

When the client wanted to replicate this for their international store, I adapted the same codebase with the specific variations each market needed. Two stores, one codebase, independent configurations. No second subscription, no duplicate setup.

When to use the app, when to build

There's no universal answer, and the case above is one specific context, not a general rule. But there are patterns worth thinking through:

• The app comes with a team behind it: Months or years of development, real usage across thousands of stores, and support. If it has good reviews and covers your use case, it probably works. That's not nothing. A custom build, especially early on, carries execution risk: things don't always come out as expected the first time, edge cases surface in production, and you own the maintenance permanently.
• Apps are built for the common case: They're configurable within their own constraints, and those constraints are invisible until you hit them. At some point a client will want something the app doesn't support, and you'll either patch around it or replace it entirely.
• Cost is more nuanced than it looks: An app at $30/month is cheap until you're paying it across three stores, or until you've been paying it for three years. A custom build is expensive upfront but the cost is fixed. If the feature is long-lived and the store has a development relationship already, the math often favors building.
• Control is the other dimension: With a custom build you own the code, the design, and the behavior. You can change anything. With an app you're working within someone else's architecture, and if they change pricing, deprecate a feature, or shut down, you have a problem.

The honest summary

Default to the app, it's the lower-risk starting point for most stores. Reconsider when the use case is specific enough that the app's constraints will eventually bite you, when cost compounds across stores or time, or when the development relationship already exists and the hours are there.