A brand wants a “fully custom Shopify site.” That phrase could mean three very different jobs: improving a storefront theme, building an app for a unique operational workflow, or moving the customer-facing site to a headless architecture. Each has a different maintenance cost and a different reason to exist.
Start with the constraint you can name
Begin with a specific limitation. Is the team unable to tell the product story within the current theme? Is a checkout-adjacent business process awkward? Does merchandising depend on data from another system? Shopify’s developer documentation treats apps, themes and headless storefronts as distinct paths; the problem should determine which path is useful.
- Write the desired customer journey before choosing a framework.
- Identify what the platform already handles well.
- Estimate the operational owner of any new service or integration.
A theme can be a serious product surface
A well-crafted theme can deliver strong visual identity, clear product information and fast mobile browsing while keeping many standard commerce features within the platform’s normal workflow. If the challenge is storytelling, discoverability or a more useful product page, start there. Audit templates, content structure, filters and the buying journey before adding architectural complexity.
Where a back-office operation is the problem, a custom app may be the right boundary. Think about inventory rules, approval flows or integration with an internal system. Define the inputs and outputs and decide who supports the app when a platform API changes.
What headless changes
A headless storefront gives greater freedom over the presentation layer and its integrations. It also makes your team responsible for more of the storefront behavior and its deployment. Preview workflows, performance budgets, analytics, error states, accessibility and third-party scripts all need an owner. A striking design is only an asset if the buying flow remains reliable.
Prove the need with one customer journey that cannot be delivered well enough through the simpler route. Price the build and the continuing operational work, not just the launch. Ask how editors will update content, how promotions propagate and how the team will diagnose a failed checkout path.
- Prove the differentiating journey in a small prototype.
- Test mobile product discovery and checkout handoff.
- Write down who owns content, deployment and integration incidents.
A workshop question for the merchant
Ask a merchant to describe the last three updates that took too long: changing a product page, launching a promotion and correcting a stock discrepancy. If the difficulty is editing product information, improve content structure and theme components. If stock is wrong because two systems disagree, define an integration with clear ownership. If the brand cannot express a unique browsing journey on the existing surface, prototype a custom storefront.
Show the merchant a working version of one journey before signing up for the most ambitious architecture. Measure editorial time, mobile buying friction and support burden. The right route may be less glamorous on a system diagram and far better for the people running the store.
- Observe the editing workflow.
- Prototype the differentiating customer journey.
- Budget for support after launch.
The decision in one meeting
Put three columns on the table: customer benefit, implementation cost and ongoing responsibility. Evaluate theme, app and headless routes against the same journey. If a theme meets the experience goal, spend the saved complexity budget on better photography, product data and customer support. If it cannot, specify exactly why before moving up a layer.
The result should be a storefront architecture that makes the brand distinctive and the business operable. Good engineering does not chase the most bespoke stack; it gives the team enough control to make the customer experience genuinely better.