Every Shopify kickoff hits the same fork: install an app, or build a thin custom feature into the theme and a small backend.
Shopify build vs buy is not a purity test. It is a cash-flow and control decision. Apps ship faster. Custom work you own ages better when the feature is core to how the store sells.
The real cost of “just install an app”
The sticker price is monthly. The bill you feel later is:
- Another script on the storefront (the theme tax nobody puts in the SOW)
- Another admin surface your team must learn
- Data living in a vendor you cannot export cleanly
- A feature that disappears or changes pricing when the app pivots
- Checkout or customer-account constraints if you are not on the right plan
I do not hate apps. I hate stacking five of them to approximate one workflow the merchant will still ask me to “make feel native” three months later.
When I buy (install) without guilt
I reach for an app when:
- The problem is commodity (reviews, basic subscriptions, loyalty with a known provider)
- The app is the category leader and the merchant already trusts it
- Building it well would mean owning tax, carrier, or compliance logic I should not recreate
- The merchant needs it live before a campaign next week, and a theme snippet will not cut it
- Uninstall risk is acceptable — the feature is not the brand’s moat
Example: a reviews widget from a mature vendor. I can theme it. I should not rebuild moderation, photo uploads, and syndication from scratch for a mid-size catalog.
When I build a small custom surface
I build when:
- The workflow is specific (B2B quote fields, region-specific metafields, a packing rule no app models)
- Performance matters and the app injects a heavyweight script on every template
- The merchant already pays for a developer retainer and the feature is a few hundred lines of Liquid plus a Shopify Function or a tiny custom route
- Data must stay in Shopify metafields or metaobjects they already own
- The app options all require Plus, or force a checkout hijack the brand does not want
Example: a size guide driven by metaobjects, rendered in a section, editable in admin. That is careful Liquid and content modeling — not a monthly app that also loads a chat SDK.
A decision table I put in proposals
| Signal | Lean buy | Lean build |
|---|---|---|
| Time to first value | Days | Weeks unless tiny |
| Recurring cost | Monthly forever | Build once, maintain |
| Storefront JS weight | Often high | You control it |
| Admin UX | Vendor’s | Yours or native |
| Exit cost | Export pain | You keep the code |
| Compliance-heavy | Prefer specialist app | Avoid reinventing |
I also ask: if this vendor doubles price or sunsets the SKU, does the store break? If yes, and the feature is revenue-critical, build — or at least abstract behind your own metafields so the UI can change without rewriting the catalog.
Hybrid patterns that work
Most sober builds are hybrids:
- App for hard infrastructure, theme for presentation — subscriptions engine from a vendor; custom Liquid for how plans appear on the PDP.
- Shopify-native first — metafields, metaobjects, Shopify Functions, Checkout Extensibility — before a third-party cart drawer.
- Thin custom admin — a small internal tool that writes metafields in bulk (the pain that pushed me toward MetaGrid / BulkFix-style thinking) instead of paying per-seat for a generic spreadsheet app.
Do not hybrid by installing three apps that each own a slice of the same customer journey. That is how you get double discount codes and race conditions at checkout.
Scope the maintenance, not just the launch
Custom is not free. Themes update. APIs deprecate. Online Store 2.0 sections need regression checks. I price a maintenance lane when the feature is custom: quarterly smoke test, dependency bumps, and a note in the repo about why we did not use App X.
Apps need maintenance too — config drift, theme app extension conflicts, and “it broke after the sale theme change.” Neither path is zero ops. Buyers who pretend otherwise are shopping for surprise invoices.
App stores reward demos; your storefront rewards restraint
App listing videos are optimized for install. Your LCP budget is optimized for revenue. Those incentives conflict. On calls I ask the merchant to open the app’s theme embed list and count global scripts before we talk features. If three “must-have” apps each inject on every template, we are not choosing features — we are choosing a performance regression with a monthly fee.
A useful exercise: write the user story in one sentence without naming an app. “Merchandiser can attach a region-specific size chart reusable across products.” That sentence often points at metaobjects. “We need PCI-compliant subscription billing with dunning.” That sentence points at a specialist app. Language first, vendor second.
Ownership and the two-year spreadsheet
I put a crude two-year cost next to build estimates:
- App: monthly fee × 24, plus estimated theme conflict hours, plus switching cost if we leave
- Build: fixed build, quarterly maintenance hours, hosting if any, documentation
Custom is not automatically cheaper. A poorly scoped custom checkout experiment can exceed years of a stable app. The spreadsheet is there to kill romance on both sides — “apps are always lazy” and “custom is always cleaner.”
Staffing reality from a remote consultant
Working from Karachi with overlapping hours into EU and US mornings, I care about who operates the feature when I am offline. Apps with solid admin UX win when the merchant team is non-technical. Custom admin screens win when the workflow is weird and training two people is cheaper than bending a generic app.
Handoff docs matter either way: uninstall steps for apps, runbooks for custom. Build vs buy is also “who gets the pager.”
Red flags that mean postpone
- The feature request changes every call (build will thrash; app config will thrash too — clarify first)
- Legal has not approved the customer-facing promise the feature implies
- The store is mid-theme migration (do not stack reversible app debt on a moving base)
- Nobody can name the success metric (AOV, conversion, support time) — then you are decorating
I would rather delay two weeks and pick once than install, rip out, and rebuild.
How I recommend on a call
I ask four questions out loud:
- Is this feature unique to how you sell, or is it table stakes?
- What is the two-year cost of the app versus a fixed build plus light retainer?
- Where does the data live when you leave?
- What does this do to LCP and checkout?
If the answers point at commodity and low exit risk, buy. If they point at identity and control, build small and ship. The wrong choice is installing something heavy because it had a pretty demo, or building a platform because an app felt “not engineered enough.”
I help merchants make that call from Karachi — Shopify themes, custom surfaces, and AI features with a cost ceiling — and I would rather kill a shiny app than slow the store for a checkbox.