Shopify theme or custom development: what should your brand buy?

A request for a ‘premium custom website’ hides several different purchases. You might want distinctive photography, a more useful product page, a subscription selector, a guided routine, or simply a cleaner menu. Those needs have different technical implications. Ask the agency to show which requirements are theme configuration, which require a small extension, and which need a separately maintained application.

Write requirements as observable actions. ‘Our coordinator can add a new shade without asking a developer’ is testable. ‘The site should feel elevated’ needs a design reference and an agreed execution, but does not by itself require a custom storefront. If a proposal jumps directly from a mood board to a large development budget, the missing step is a requirements demonstration.

There is a useful middle ground between leaving a theme untouched and rebuilding everything. A theme can carry the common shopping patterns while a small number of custom sections explain a proprietary product or treatment. The important question is how those sections behave when products, images and copy change.

Ask to see the proposed theme with your actual longest product name, a sold-out variant, several image ratios and a translated phrase. A beautiful demonstration store may avoid precisely the awkward content your business needs to publish.

In Shopify’s Dermalogica case study, Kevin Rowlands describes the value of an off-the-shelf solution and greater agility across markets. The practical lesson is that an established brand can choose a platform because it reduces operational friction. The vendor’s reported results do not establish what another brand will earn from the same choice.

For your brief, translate that example into a question: which tasks should become easier for the people running the store? List a campaign launch, a regional assortment change and a product update. Have the supplier demonstrate the proposed workflow for each task before accepting the claim that a custom build is necessary.

Consider an illustrative Korean skincare brand selling six products in the US. It needs ingredient explanations, a routine order, texture clips and two bundle offers. The brand first assumes it needs a bespoke storefront because its existing site feels generic. A requirements session finds that five needs fit theme sections and structured product fields; only the routine comparison requires a small custom section.

The brand can now request two comparable estimates: a configured theme with that section, and a fully custom alternative. Each estimate must include the same product content, accessibility checks, analytics validation and training. Comparing equivalent work prevents a low headline price from winning because it excludes the hard parts. No conversion improvement is assumed in this example.

Initial development is only one line in the decision. Request separate amounts for theme or software licenses, app subscriptions, custom development, content loading, quality assurance, training and maintenance. Ask what happens when the theme vendor releases an update. Can the team adopt it directly, or must a developer reconcile changes?

In a fictional comparison, a $9,000 implementation plus $300 monthly support costs $12,600 in the first year. A $16,000 implementation plus $900 monthly support costs $26,800. Those are arithmetic examples, not market rates. The more expensive approach can still be sensible if it solves a valuable constraint, but the proposal should make that constraint explicit. Include your staff’s editing time and any required hosting in the real comparison.

A paid discovery or prototype can reduce uncertainty when the difficult requirement is genuinely unresolved. Scope it around one interaction and a written conclusion: achievable in the theme, achievable with a contained extension, or requires a larger architecture. Agree who owns the prototype and whether it can be reused.

The proof should include a nondeveloper editing the content, an empty state, an error state and a mobile view. If a proposed routine builder only works with six hardcoded products, it has not demonstrated how the brand will add a seventh. A prototype is useful when it answers the purchase question; an elaborate presentation without working behavior leaves the uncertainty intact.

Consider a subscription selector that must coexist with one-time purchases, bundles and a market-specific offer. Ask the supplier to demonstrate those combinations with the proposed theme and app before estimating a custom replacement. The requirement may fit existing tools, or it may expose a real limitation. Either result is useful if it is documented. Avoid accepting a demonstration that covers only the default product while the difficult bundle is left for later.

Also ask what happens when a dependency changes. If an app supplies the underlying subscription behavior, a custom visual layer does not remove that dependency. The proposal should identify which provider owns the data, which component owns the interface and who investigates a failure between them. This matters when the brand calls for help after launch: two suppliers blaming each other can consume more time than the original design decision saved.

Write an acceptance scenario with the expected price, selected product and customer action. Have the agency show the complete path in preview, then ask the brand’s editor to change the relevant content. If the customer journey works but routine editing requires code changes, price that operating burden explicitly. The final decision can then favor custom work for a demonstrated reason rather than because the term sounds more sophisticated.

For every custom component, require its purpose, editable fields, dependencies, release instructions and known limitations. Store code in an account the business controls and record where configuration lives. A future agency should be able to distinguish intentional behavior from a forgotten experiment.

Before accepting the project, ask a team member to change a headline, replace a product image and prepare a campaign page in preview. Record where they need help. These observations can reveal that the chosen implementation is too fragile for daily use even when the front end looks excellent. The right purchase balances a distinctive customer experience with an editing process your actual team can sustain.

Use these guides when the next question goes beyond the scope of this article.

Download the completed tables as a CSV, then replace the example inputs and add your evidence, owner and review date. Illustrative figures are teaching examples, not default targets.