Quick answer
Start with native Shopify if the platform already solves the problem cleanly. Use a third-party app when the need is common, the app is well maintained, and the cost is easier to justify than rebuilding the feature. Build custom when the workflow is strategic, unusual, tightly connected to operations, or important enough for the business to own.
The best Shopify solution is not always the most custom one. It is the one the store can afford, understand, maintain, and trust after launch.
The decision in plain English
Most Shopify requests fall into one of three lanes:
- Native: Use Shopify settings, theme features, metafields, metaobjects, discounts, customer segments, Flow, Markets, B2B, or other platform tools.
- App: Install a third-party app when the feature is common and the app solves it better than a quick custom build would.
- Custom: Build a custom app, integration, extension, theme feature, or app proxy when the business needs something specific enough to own.
The mistake is jumping straight to one lane without asking what the job actually requires. Some teams install an app for every small problem. Some teams custom-build features that Shopify already handles. Some teams avoid apps so aggressively that they spend more money recreating standard functionality.
The practical answer is to choose the lowest-maintenance solution that still protects the business requirement.
What counts as native Shopify?
Native does not mean basic. In Shopify, native can include a lot more than theme settings.
Depending on the store and plan, native or platform-first tools can include:
- Theme sections, blocks, menus, templates, and app blocks.
- Metafields and metaobjects for structured content and product data.
- Customer segments, discounts, markets, shipping profiles, and tax settings.
- Shopify Flow for trigger, condition, and action-based automation.
- Shopify B2B features for companies, locations, catalogs, and payment terms.
- Shopify Functions, checkout extensions, and validation rules when developer work is needed on the platform layer.
A native solution is usually best when the need is stable, understandable, and close to what Shopify already supports.
Use native when the problem is simple or structural
Native is the first place to look when the request is about core store setup, content structure, merchandising, or light automation.
Examples:
- Product specifications belong in metafields before they belong in a random theme note.
- Reusable editorial content may belong in metaobjects before it becomes a custom-coded section.
- Basic order tagging often belongs in Shopify Flow before it becomes a custom app.
- Product availability by market should start with Markets and sales channel settings.
- Homepage and product page layout should start with theme sections before a custom landing-page system.
Native usually wins when the store team needs to edit the feature later without a developer. It also reduces vendor dependency and keeps the setup easier to understand.
Use an app when the problem is common and the app is mature
An app is often the right choice when many stores have the same problem and the app vendor has already solved the boring parts: admin screens, settings, edge cases, support, updates, and integration details.
Common app-friendly areas include:
- Product reviews and ratings.
- Subscriptions.
- Loyalty and referrals.
- Returns and exchanges.
- Back-in-stock alerts.
- Email, SMS, and retention tools.
- Advanced search, filtering, and recommendations.
- ERP, shipping, accounting, or support integrations.
Before installing, check the app’s pricing, support history, theme impact, data access, performance footprint, and uninstall behavior. Shopify’s app install flow asks merchants to review app data access requirements before authorizing an install. That is not a throwaway step.
Build custom when the workflow is strategic
Custom work makes the most sense when the feature affects how the business actually operates.
Good candidates for custom work include:
- A B2B sales rep portal with company-specific rules.
- A product configurator that affects pricing, fulfillment, engraving, bundles, or inventory.
- An integration with an ERP, OMS, PIM, warehouse, or internal system.
- A custom approval workflow that cannot be modeled cleanly in Flow.
- A storefront experience that must behave differently from a generic app pattern.
- A checkout or cart rule that needs a Shopify Function or validation logic.
- An admin tool for internal teams that cannot live comfortably in spreadsheets.
Custom is not automatically better. It just means the store is choosing ownership. Ownership can be powerful, but it also means documentation, hosting, testing, API changes, and maintenance.
The hidden costs of each choice
| Choice | Hidden cost | Best when |
|---|---|---|
| Native | May not cover every edge case. Can require compromise. | The need matches Shopify’s platform model. |
| App | Monthly fees, theme impact, vendor dependency, data access, uninstall risk. | The need is common and the app is proven. |
| Custom | Build cost, maintenance, documentation, hosting, future developer support. | The workflow is strategic or unique. |
A practical decision rule
Use this order before making the call:
- Can Shopify do this natively? Check admin settings, theme sections, metafields, Flow, Markets, discounts, B2B, and Shopify’s current platform tools.
- Can the theme handle it cleanly? If it is mostly presentation, a theme setting or section may be enough.
- Does a reputable app solve most of it? If the feature is standard, do not custom-build just to feel custom.
- Is the remaining gap actually strategic? If the gap affects operations, margin, sales workflow, or customer experience, custom work may be worth owning.
- Who maintains it later? The answer is incomplete until someone owns updates, testing, support, and documentation.
Examples
Order tagging
Start with Shopify Flow. If the logic is based on order data, customer tags, products, risk, or location, Flow may handle it without a custom app.
Product specs
Start with metafields and metaobjects. If the store needs structured specs, compatibility, materials, dimensions, or repeated content, custom theme code should read from structured data instead of hardcoded copy.
Product reviews
Use an app. Reviews need moderation, email capture, schema, imports, star display, and support. That is rarely worth building from scratch for a normal store.
B2B sales rep ordering
This may need custom work. Native Shopify B2B can handle companies, locations, catalogs, and payment terms, but a sales rep portal or unusual order creation workflow may require custom storefront or app logic.
Checkout restrictions
Do not hack this in the theme. For real cart or checkout rules, look at Shopify’s checkout extensibility and Functions model, then decide whether a custom build is needed.
Common misunderstanding
Custom is not the same thing as professional. A clean native setup can be more professional than a fragile custom feature. A good app can be smarter than rebuilding a commodity feature. Custom work is best when the business reason is strong enough to justify ownership.
How to test this
- Write the requirement in one sentence before picking a tool.
- Check whether Shopify, Flow, metafields, metaobjects, Markets, B2B, or discounts already cover it.
- Price the 12-month cost of any app, not just the monthly fee.
- Check whether the app changes theme performance, checkout, or product page behavior.
- Ask what happens if the app is uninstalled or the custom developer is unavailable.
- Test the decision on a duplicate theme or staging workflow before changing the live store.