Most features a store owner wants can be added in more than one way. A size chart could be a theme setting, an app or a few lines of custom code. A product badge, a delivery estimate, a gift note field or a sticky add-to-cart button is the same. Each route works on day one. The differences show up later, in the monthly bill, the page speed, the work needed when the theme changes and how hard it is to undo.
This guide sets out the three main routes, how they compare over time and a simple way to decide. It uses Shopify terms, but the reasoning applies to most hosted store platforms.
Key takeaways
- Theme setting first, app second, custom code third is a sensible default order to check, not a strict rule.
- Apps move maintenance to the developer but add a dependency, a recurring cost and often storefront code.
- Custom code has no monthly fee, but someone has to maintain it, especially when you change themes.
- Lock-in is about data and habits, not just contracts. Ask how you would leave before you start.
- Hire a developer for changes you cannot test or undo yourself.
The three routes
| Route | What it is | Typical examples |
|---|---|---|
| Platform feature or theme setting | Something already built into your platform or theme, switched on and configured | Product badges, announcement bars, simple size charts, related products |
| App | Software from a developer, installed from the app store, often with a subscription | Reviews, subscriptions, loyalty programs, advanced search, back-in-stock alerts |
| Custom code | Changes to theme files or a small custom app, written for your store | A custom product page section, a specific layout, a small piece of logic |
There are mixed routes too. Many apps add features through theme app blocks that you place in the theme editor. A developer can build a small custom app that only your store uses. The comparisons below still apply.
Start with what you already have
Before anything else, check whether the feature already exists:
- Platform features. Platforms add features regularly. Something that needed an app a few years ago may now be a setting.
- Your theme’s settings and sections. Many themes include features such as size charts, badges, pop-ups, color swatches and delivery messages. Look through the theme editor and the theme’s documentation.
- Tools you already pay for. Your email platform, reviews tool or help desk may already cover it.
If one of these does the job well enough, it is usually the cheapest and lowest-risk choice. The platform or theme developer maintains it, it is built to work with your theme, and turning it off is simple.
The limitation: built-in features are generic. If you need something specific to your store, they may not stretch far enough.
How the routes compare over time
| Factor | Theme setting | App | Custom code |
|---|---|---|---|
| Upfront effort | Low | Low to medium | Medium to high |
| Ongoing cost | Usually none beyond your theme and plan | Often a recurring fee | Developer time when changes are needed |
| Maintenance | Theme or platform developer | App developer | You or your developer |
| Speed impact | Usually small | Varies widely; some apps load scripts on every page | Usually small if written well |
| Theme change | Depends on the new theme having the feature | Usually carries over if the app supports the new theme | Often needs to be rebuilt or copied over |
| Data | Stays in your store | Often held partly by the app | Stays in your store |
| Removal | Switch it off | Uninstall, then check for leftovers | Remove the code, carefully |
| Flexibility | Limited to the settings offered | Limited to what the app offers | Whatever you specify |
Cost over time
A monthly fee looks small on day one and adds up over the years. Custom code looks expensive on day one and then costs little until something changes. To compare, work out a rough total over a period you can plan for, such as three years:
- App: monthly fee × number of months, plus your setup time and any price increases you expect as you grow.
- Custom code: development cost, plus an estimate of maintenance, such as a few hours of developer time each year and a rebuild if you change themes.
- Theme setting: setup time only, unless it needs a theme upgrade.
Use real quotes and your own plans for the numbers. The result is not exact, but it often changes the decision. A simple feature you will keep for years may be cheaper as custom code; a complex one that needs constant updates is usually cheaper as an app.
When an app is the better choice
- The feature needs ongoing service, such as sending emails, storing reviews, processing subscriptions or syncing with other systems.
- It depends on outside changes like shipping carrier rules, tax rates, marketplace requirements or platform API updates. The developer keeps up so you do not have to.
- It needs a back end: a database, scheduled jobs or an admin interface for your staff.
- You want to try something quickly and remove it if it does not work.
Before installing, check what the app can access and how it adds code to your storefront. Our checklist on how to choose Shopify apps and our guide to Shopify app permissions cover what to look for.
When custom code is the better choice
- The change is small and stable, such as a layout tweak, a custom section or a fixed message that rarely changes.
- No app does exactly what you need, or the apps that come close bring many features you do not want.
- Speed matters and the app options load heavy scripts for a small visible feature. Our store speed checklist explains how to measure that.
- You want to own it with no recurring fee and no dependency on another company.
Custom code has a cost that is easy to forget: someone has to understand it later. Ask for comments in the code and a short note explaining what was changed and where. Keep that note with your store records.
Lock-in
Lock-in is how hard it is to leave once you have started. It is not only about contracts.
| Type of lock-in | Example | How to reduce it |
|---|---|---|
| Data | Reviews, subscribers or loyalty points held inside an app | Check export options before you start; export regularly |
| Theme | App code added directly to theme files | Prefer app blocks and embeds; document any manual changes |
| Habits | Staff workflows built around one tool | Write down the process, not just the tool |
| Customer-facing | Customers used to a feature, such as points or a wishlist | Plan how to migrate or retire it before you switch |
| Custom code | Code only one developer understands | Comments, documentation and a copy of the original theme |
Ask the exit question before you start: if we stopped using this in a year, what would we lose and how much work would removal be? Our guide to auditing your Shopify apps covers the practical side, including exporting app data before removal.
A simple decision path
- Is it a platform feature or theme setting? Use it, if it does the job well enough.
- Does the feature need ongoing service, data storage or outside integrations? An app is likely the better fit.
- Is it a small, stable visual or layout change? Custom code is worth pricing.
- Would the app load heavy code for a small feature? Compare with custom code.
- Will you change themes soon? Prefer options that survive a theme change, or wait.
- Who will maintain it? If the answer is nobody, choose the route that needs the least maintenance.
When to hire a developer
Some changes are safe to try yourself on a duplicate theme. Others are better left to someone who does this work regularly. As a rule of thumb, hire help when:
- The change touches checkout, payments, taxes or order processing.
- You cannot test it properly, for example logic that depends on customer accounts or specific cart contents.
- It involves an integration with another system, such as an accounting tool or a warehouse.
- You would not know how to undo it if something went wrong.
- You are removing a lot of leftover code after uninstalling several apps. Our guide to removing leftover app code explains what is involved.
A good brief saves time and money: what the feature should do, where it should appear, what should happen in edge cases, how you will test it and what documentation you want at the end. Our guide to working with a freelance store developer covers briefs, access and handover.
Common mistakes
- Installing an app for a feature the theme already has.
- Comparing an app’s monthly fee with the one-off cost of custom code without looking at the years ahead.
- Letting a developer edit the live theme without a backup.
- Accepting custom code with no documentation.
- Building a feature into theme files shortly before a planned theme change.
- Keeping an app for one small feature while paying for, and loading, many others.
FAQ
Is custom code always faster than an app?
No. Well-built apps can be light, and poorly written custom code can be slow. Measure the actual pages before and after rather than assuming.
What happens to custom code when I change themes?
Changes made to theme files belong to that theme. When you switch, they usually need to be copied or rebuilt in the new theme. Keep a list of custom changes so nothing is forgotten.
Can I start with an app and move to custom code later?
Yes. Many stores do this once they know exactly what they need. Export the app’s data first and plan the switch for a quiet period.
Bottom line
Check built-in options first. Use an app when the feature needs ongoing service, data storage or integrations, and custom code when the change is small, stable and worth owning. Compare cost over a few years rather than on day one, ask how you would leave before you start, document whatever you choose, and hire a developer for anything you cannot test or undo yourself.
