A better product page can’t record a showroom payment.

Shopify can stay the backend

Shopify supports a custom frontend on top of its commerce backend. In the documented headless setup, customers browse products and build a cart in your frontend, then pay in Shopify Checkout. A framework like Next.js can build that interface without replacing checkout.

An external CRM can connect through authorised APIs as well. That extends the operation around the store; Shopify still owns the backend jobs you leave with it. Decide who owns what before you create another database full of products, customers and orders.

Theme or custom storefront

Shopify themes are built with Liquid, HTML, CSS, JavaScript and JSON, inside Shopify’s theme system. If the experience you need fits that system, a theme is the sensible place to start.

A custom storefront is worth investigating when specific journeys need more control. It also hands your team new work: hosting, API integration, cart behaviour, analytics, links into checkout and ongoing maintenance.

Reusing templates is a separate decision. You can customise selected sections of a theme, or reuse interface components in a Next.js app. Either way, a familiar navbar and footer leave more effort for the product and booking flows. Reuse doesn’t decide where the storefront runs.

For this retailer, the Next.js prototype let us discuss the experience before we had authenticated Shopify access. It didn’t show that a theme was unsuitable, or that a fully custom storefront was the right production choice.

Know which API does the work

Shopify splits these responsibilities across different interfaces.

Plan for the notification that never arrives

The Admin API needs an app token and permissions the merchant grants. Reviewing the public storefront can’t confirm those permissions or show how the merchant’s internal records are organised.

Webhooks keep an external service current, but deliveries can be missed. Shopify recommends reconciliation jobs that fetch changes through the API, so a CRM needs a way to catch up after a failed notification or downtime.

A single API for the frontend can combine all of this. It still needs ownership and conflict rules underneath. Write down which system owns stock, quote totals, payment balances and the final call on fulfilment.

What the plan table actually changes

At the time of writing, Shopify’s India pricing page lists these monthly equivalents, with yearly billing, for the standard plans. Plus has its own term structure.

Check the feature against your workflow

We checked these figures against Shopify’s India pricing, Plus pricing and partial-payment documentation. Prices change, and gateway processing charges and custom-system costs are separate.

A higher plan can make a feature available. You still have to confirm it works with your payment provider, sales channel and customer journey. A custom frontend doesn’t change what your plan includes.

Where MCP fits

MCP gives an AI assistant a structured way to call tools. Shopify’s developer tooling can help with documentation and API schemas, and its commerce tools let agents work with catalogues and other shopping functions. Authenticated customer-account tools are a separate surface.

These surfaces move. Shopify’s current migration guide says the old catalogue and cart tools at /api/mcp were removed, and points developers to UCP at /api/ucp/mcp. Build against the current documentation, not an older article.

MCP doesn’t replace authentication, a supported checkout flow or payment reconciliation. Use it when an assistant needs tools for a defined task, and keep the payment and order rules explicit in the application.