Most Shopify planning conversations contain a moment that goes by too fast. The team has spent two hours on checkout customization, catalog structure, and storefront performance. Then, fifteen minutes before the meeting ends, someone asks: "and what about the customer account area?" The decision deserved an hour. It gets five minutes, ends with "we'll go custom" or "Shopify's accounts are fine," and the consequences show up eighteen months later when retention numbers don't match the deck.
The decision keeps biting because most teams frame it the wrong way. They ask "what can we customize?" when the question that matters is "does our retention depend on this?" The first is a feature comparison. The second is a business-model question, and the right customer-portal architecture follows almost entirely from it.
This year the decision is also happening at a forcing moment. Shopify deprecated legacy customer accounts in February 2026 and will announce a final sunset date before the year is out. Brands that picked an architecture in 2022 are reopening the choice whether they planned to or not.
If you're going to reopen it, reopen it correctly.
The decision people get wrong
The most common mistake is choosing a custom build because the brand team wants control over the visual experience of the account page. It's a reasonable instinct. Most luxury and premium brands operate on the principle that every touchpoint should feel like the brand.
But brand fidelity on the customer account page is not, on its own, a sufficient reason to take on a perpetual maintenance contract.
On one luxury engagement, we walked the client away from a custom build whose only real justification was branding. The reason is operational, not philosophical. A custom portal is a second application your team owns. It has to be deployed, monitored, patched, and updated every time Shopify ships a primitive that matters or an upstream app changes its API. The cost of those updates compounds. Two years in, the maintenance bill usually outweighs the gap between the bespoke UI and what Shopify's design system could have delivered.
The four architectures
The maintenance argument isn't an argument against custom builds. It's an argument for choosing on operating cost and business fit rather than on visual control. Four architectures are available on Shopify today, and they differ less in what they can do than in what they cost to run and what kind of business they suit.
One caveat before the tour. These four are rarely mutually exclusive in practice. Plenty of stores run native accounts for orders and addresses, hand subscriptions to Recharge's portal, and bolt on a single custom page at /apps/. The real question is usually not which architecture you use, but which one owns the primary surface and how much of the experience you're willing to let the others define.
Shopify Customer Accounts with UI extensions
Shopify hosts the portal and renders it. You extend it with UI extensions, the same model checkout UI extensions established: app blocks on the order index, order status, and profile pages, plus full pages of your own inside the account area.
The Customer Account portal with some custom blocks
What you get is everything Shopify ships, without your team touching it: passwordless login via Shop Pay, native order tracking, self-serve returns, address management. Apps that have built UI extensions plug in without integration work.
What you accept is the design system. Polaris-grounded layout, no CSS override, no bespoke interaction patterns. You ship features at the pace of Shopify and whichever app vendors are building extensions for the area you care about.
This is the right answer for most brands, especially brands where the post-purchase moment is transactional: a customer comes in, checks an order, updates a card, leaves. The native experience does that well, and it improves every quarter without your team writing a line of code.
App-based portal
Many of the apps your store already runs ship their own customer-portal UIs (e.g., Recharge, Loop). You can drop them in as embedded pages or theme blocks, point your customer there, and let the vendor handle the rest.
An example of the Customer Portal offered by Loop, a popular subscriptions app. Everything is configurable from the app itself, without the need for custom integrations
What you get is speed. No build, no infrastructure, and a surface each vendor keeps current on your behalf.
What you accept is fragmentation. A customer at a typical mid-market DTC brand running three of these apps learns three sidebars, three navigation models, and sometimes three login flows just to manage one relationship with the brand. Each app vendor is a competent designer for their own surface. Together they're a patchwork. You can paper over some of the visual difference with theming, but the interaction patterns aren't yours to set.
The app-based approach is right when one app handles most of what customers do in your portal. A subscription business where the subscription app carries 80% of the activity can live with this. A brand where post-purchase activity is spread across three apps usually can't.
External custom portal
The external approach is a standalone web application (your own Rails, Next, or whatever stack) running on a subdomain like account.brand.com.
It authenticates against Shopify via the Customer Account API and integrates with subscription, loyalty, returns, and other vendors through their APIs. The portal lives outside the theme entirely.
The custom customer portal we built for Cometeer. It connects with Recharge APIs to manage subscription data and exposes several custom-built functionalities, including a bespoke coffee box management experience powered by their proprietary recommendation algorithm.
What you get is total freedom. No design ceiling, no platform conventions to inherit, no Liquid object shapes to reconstruct. The information architecture is yours, the performance characteristics are yours, every interaction is yours.
What you accept is the cost of running another application: deploy, monitor, secure, scale. Every integration depends on an API surface someone else controls. If Recharge sunsets an endpoint or Loop changes a payload, you adjust.
Take Cometeer as an example. We built their custom portal because their business needed it: subscription management with a bespoke recommendation algorithm, churn flows tuned to their economics, and a native mobile app. Recharge's stock portal was too slow and too rigid for the standard they held themselves to. The Cometeer case study covers what the engagement looked like.
Embedded custom portal
The embedded approach builds a custom portal that lives inside your storefront, served from your own domain. Mechanically, you build a Shopify app exposed via app proxy at a path like /apps/account/. When a customer hits that path, Shopify forwards the request to your app, which returns either JSON (your theme's JavaScript renders the response) or Liquid (Shopify renders it server-side, and the Liquid can call snippets already in your theme).
The Liquid path is the one most teams haven't seen, and it's the reason to pick this architecture. It lets the portal render with the same components the rest of the storefront uses. Your store locator, your product card, your typography: all of it stays in one place, applied consistently to a custom account experience.
The plan management screen from the portal we built for DogHeroes, where customers switch between dogs and adjust the food plan for each one. The layout, typography, and components come from the theme itself.
What you get is theme parity. A custom experience that inherits the storefront's components and content instead of reimplementing them.
What you accept is the same infrastructure burden as the external option: the Shopify app still has to be deployed, monitored, patched, and maintained against an evolving platform.
Take DogHeroes as an example. Their portal is a Rails app sitting behind an app proxy at /apps/paws/, so a customer who opens /apps/paws/subscriptions never leaves the storefront. Rails handles authentication and the subscription data, then answers with Liquid that calls snippets kept in the theme itself, named dogheroes--portal--*.liquid. Shopify renders the result. The plan management screens look like the rest of the store because they are built from the rest of the store.
This earns its place when you need a custom portal and you need it to reuse pieces already in the theme: a store locator, a configurator, a content section that powers part of the storefront experience.
The questions you should actually ask
Polaris and UI extensions can replicate almost any account-page UX a brand can describe, if you spend the engineering hours. Whether those hours move your business is a different question, and it's the one that belonged at the top of the agenda.
The shortest test we know: ask what a customer does in your account area and how often. If the answer is "checks an order, updates a card, redeems points twice a year," native is fine. The ceiling on what you can build there is largely irrelevant to whether they come back.
If the answer is different, if your retention loop runs through the account page, if customers spend real time there managing subscriptions, reconfiguring upcoming orders, working through churn-prevention flows, learning a complicated product, then every step of friction you remove compounds.
For most brands the account page is a service surface. For a few, it's the room the customer lives in.
Which one you're running settles the architecture, and it comes down to four questions:
- Does the customer-portal experience materially affect retention, or is it a transactional necessity? If it's transactional, stop here: native accounts, or an app portal if one vendor already owns the surface. If it's material, keep going.
- Is one app responsible for more than 80% of customer-portal activity? If yes, app-based stays honest even at the material end. If no, fragmentation will hurt and keep hurting, and you're building something custom.
- Do you need to reuse anything already in the theme, like components, content, or configurators? Yes: embedded. No: external is simpler.
- Do you have, or want, a mobile app within two years? If yes, weight external more heavily than question 3 suggests. The portal's API layer is also the mobile app's API layer, and an external build gets you there with less rework.
Build the portal your business model needs
The right portal isn't the most flexible one or the cheapest one. It's the one that matches your brand's value proposition.
If you're sitting on this decision now, building a new store, reworking the one you already run, or revisiting a portal that hasn't aged well, we can help you make that call.
