Act II: The Antechamber
The Fifteen-Minute Decision At The End Of The Meeting
Replatform Steering Committee—Agenda 2:00 Checkout customization 2:45 Catalog & taxonomy migration 3:30 Storefront performance budget 4:05 Payments, tax, fraud 4:30 Wholesale price lists 4:45 Customer account area 5:00 Adjourn
This agenda is not from any one meeting. It is from all of them. The times shift, the line items rename themselves, the catering improves or doesn’t—but the shape holds, and the shape always does the same quiet violence to the same item. Checkout gets two hours. Catalog gets forty-five minutes and a follow-up. The customer account area gets the slot between the wholesale price lists and the door.
Fifteen minutes. After three hours of hard, prepared, well-defended argument about everything else, the part of the store where your customer goes to be a customer of yours—to manage the relationship they have already paid to enter—gets the time it takes to refill the coffee.
And in those fifteen minutes, someone says the line. “We’ll go custom. We want it on-brand.” Or its mirror image, said with a glance at the clock: “Shopify’s accounts are fine, right? Let’s not overthink it.” Nobody disagrees, because disagreeing would take longer than fifteen minutes and the next meeting needs the room. The agenda is observed. The meeting adjourns on schedule, which everyone present quietly files as evidence that it went well.
It did not necessarily go well. It went fast. Those are different things, and the difference stays invisible for about eighteen months—which is roughly how long it takes for a second group of people, the retention team, who were not in the first meeting and never saw the agenda, to end up in a second meeting, trying to work out why so many customers email a human being to do the things the account page was supposed to let them do alone.
A chapter ago, in the third hour of a discovery workshop, a senior person gestured at “a custom account portal” as one of the someday-capabilities that justified buying a far bigger architecture than the brand needed. The gesture was vague on purpose. Vagueness is what let it work as a justification—you can’t price a thing nobody will describe.
Here the gesture stops being vague. The custom account portal is no longer a someday-reason to buy something else. It is the line item itself, and it has arrived at 4:45 with fifteen minutes to live.
The decision keeps biting brands because they walk into it holding the wrong question. They ask what can we customize?—and on Shopify in 2026 the answer is almost anything, if you spend the hours. Polaris and UI Extensions can reproduce nearly any account-page experience a brand can describe, given enough engineering. So the feature comparison resolves nothing; every architecture can be talked into doing almost everything. The question that actually settles it isn’t a capabilities question at all. It is does our retention depend on this? One is a procurement question. The other is a question about which business you are in. The right architecture falls out of the second almost mechanically, and is nearly impossible to reach from the first.
Owen Caldwell is Greycott’s Head of E-Commerce, and he is the one who says the line. He says it earnestly, which is the only way Owen says anything: “I want someone who just bought a bottle of our Sicilian oil to feel like they’re still with us when they go to check where it is. It should feel like Greycott.”
This is a good instinct pointed at the wrong surface. It comes from the brand side of the building, where the governing principle is that every touchpoint should feel like the brand, and where that principle is correct. The product pages should feel like Greycott. The unboxing should feel like Greycott. The gift-set configurator that sells half the December revenue should absolutely feel like Greycott. But brand fidelity on the customer account page is not, on its own, a sufficient reason to take on a perpetual maintenance contract—and that is what a custom portal is. It is a second application your team now owns: deployed, monitored, patched, and updated every time Shopify ships a primitive that matters or an upstream app changes an API. The bill compounds. Two years in, the cost of keeping the bespoke thing alive usually outweighs the distance between it and what Shopify’s design system would have given you for nothing.
What Owen has done is inherit a requirement from the part of the org where it was true, and carry it, unexamined, into a room where it isn’t. The requirement you inherit is not the requirement you have. The customer checking where their olive oil is does not need to feel anything. They need the tracking number, in under ten seconds, on their phone, in the dark, at 11 PM, while the food is allegedly already in transit. The customer updating an expired card needs the form to work. The customer redeeming points twice a year needs to find the points. None of that is a brand experience. All of it is a service. The account page is a service surface, not a brand surface—and the moment you see it that way, most of the custom temptation drains out of the room.
It helps that Owen, of all people, has a control group. He likes Shopify in the first place because his brother-in-law runs a granola company on it and has never once called him in a panic. The brother-in-law’s granola company does not have a custom account portal. The brother-in-law’s granola company has Shopify’s native one, and a customer base that reorders granola without incident. Owen knows this. He just hadn’t connected it to the meeting until someone made the meeting run long enough to ask him what, specifically, a Greycott customer comes to the account page to do.
We have made this case before, with higher stakes and a more expensive room. On one luxury engagement we talked the client all the way back from a custom build whose only honest justification was that the account page should look as considered as the packaging. It was a real desire and a real budget, and it would have bought them a maintenance obligation in exchange for a feeling. We walked them to native. They have not missed the thing they didn’t build.
So if you are the brand director reading this—the one who is, right now, half a sentence away from saying but it has to feel like us—we are not telling you that your instinct is wrong. We are telling you it is aimed at the wrong wall. Spend it on the surfaces customers come to feel. Don’t spend it on the surface they come to use, and then pay to maintain the feeling forever.
There are four architectures available on Shopify today, and they differ less in what they can do than in what they cost you to keep alive.
The first is Shopify’s own customer accounts, extended with UI Extensions—the same model Checkout UI Extensions taught the ecosystem. Shopify hosts the portal and renders it; you bolt your additions onto it. You get passwordless login through Shop Pay, native order tracking, self-serve returns, and address management out of the box, and you get them better every quarter without your team writing a line. The apps that have built UI Extensions plug in for free. What you accept is the design system: a Polaris-grounded layout, no CSS override, no truly bespoke interaction, and a release pace set by Shopify and whichever vendors are building for the surface you care about. For most brands this is the right answer, and the reason this is the year to take it seriously is structural—Customer Account UI Extensions are reaching general availability, the classic accounts are sunsetting, and every brand that made this call in 2022 is being handed an invitation to remake it. If you’re going to reopen the decision, reopen it correctly.
The second is the app-based portal. Recharge for subscriptions, Loop for returns, Yotpo for loyalty—most of these ship their own account UI, and you can drop them in as embedded pages or theme blocks and let the vendor carry the surface. It’s fast. It’s also fragmented: a customer of a brand running three or four of these learns three sidebars, three navigation models, and sometimes three login flows, all to manage one relationship with one brand. Each vendor designs their own corner competently; stitched together they are a patchwork nobody designed. This approach is honest only when a single app carries most of what customers actually do in the account area—call it eighty percent. A subscription business whose subscription app is the account area can live here comfortably. A brand whose post-purchase life is spread across three apps cannot, and no amount of theming hides the seams for long.
The third is the embedded custom portal. Mechanically, you build a Shopify app exposed through an app proxy at a path like /apps/account/. A customer hits the path, Shopify forwards the request to your app, and your app answers—with JSON, which your theme’s JavaScript renders, or with Liquid, which Shopify renders server-side and which can call the snippets already living in your theme. That second path is the one most teams have never seen, and it is the reason embedded exists as a category. It lets a custom account experience reuse the exact components the rest of the store already uses—the product card, the store locator, the typography—applied consistently, maintained in one place. The catch is that the Liquid objects your app emits aren’t identical to Shopify’s native ones, so reusing the storefront’s product partial sometimes means reconstructing the attributes it expects. You carry the same infrastructure burden as a fully external build. Embedded earns its place in one specific case: when you need something genuinely custom and you need it to look and behave like the store it lives inside.
The fourth is the external custom portal—a standalone application on a subdomain like account.brand.com, running on whatever stack your team runs, authenticating against Shopify through the Customer Account API and talking to your subscription, loyalty, and returns vendors through theirs. What you get is total freedom: no design ceiling, no platform conventions to inherit, no Liquid object shapes to reconstruct, every interaction yours. What you accept is the full weight of running another application—deploy, monitor, secure, scale—sitting on a web of integrations whose API surfaces other people control. When a vendor sunsets an endpoint, you adjust, on their schedule. There is one downstream prize worth naming out loud: a future mobile app rides the same APIs. Same logic, same retention surface, a different shell.
Cometeer is the example we can name. Frozen coffee, by subscription, with a recommendation engine that decides which coffees arrive at your door and churn-prevention flows tuned to the exact economics of that decision. We built them an external custom portal, and we built it because their business genuinely lived there. For Cometeer, the account area is not a place a customer visits between purchases. It is the product’s home—the room where the relationship happens, week over week, every reconfiguration of an upcoming order a moment where retention is won or lost. When the mobile app came later, it rode on the APIs the portal had already built; the second investment was mostly the first one wearing a different shell. That is what the architecture is for, and it is worth the maintenance contract precisely because the maintenance is being spent on the thing the business is made of. (The fuller story—including what it costs a brand when the recommendation engine can’t explain itself to a customer—comes later in the book. Here it is only the contrast.)
Set Cometeer next to Greycott and you have the entire decision in two brands. Greycott ships products; the account page is where customers go to confirm the products are coming. Cometeer ships a relationship; the account page is where the relationship is conducted. Same platform, same four options, opposite answers—and the thing that decides it is not on the feature comparison at all.
So the test, the shortest one we know, is this: ask what a customer actually 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, and the ceiling on what you could have built there is irrelevant to whether they come back. If the answer is lives there, managing something, then every point of friction you remove compounds, and custom starts paying for itself.
Give the decision its real fifteen minutes—and it genuinely is fifteen minutes, once you’re asking the right things—and four questions settle it. First: does the account experience materially move retention, or is it a transactional necessity? Material points at custom; transactional points at native or an app. Second: does a single app carry more than eighty percent of what happens in there? If yes, app-based is honest; if no, fragmentation will hurt and keep hurting. Third: do you need to reuse things already built into the theme—components, content, a configurator? If yes, embedded; if no, external is simpler. Fourth: is there a mobile app on the roadmap inside two years? If yes, external quietly rewrites the math, because the portal and the app stop being two investments and become one.
None of these are hard questions. They are just questions nobody asks at 4:45.
Owen asked them, in the end. Not in the original fifteen minutes—in a second conversation, the one we asked for, where the only thing we really contributed was refusing to let the meeting close on schedule. He stopped asking can we make it ours and started asking what do people actually come here to do, and once that question was on the table the architecture answered itself: Shopify’s native accounts, extended where it counted, brand spent on the surfaces that earn it. We didn’t talk him out of anything. We slowed the room down until the answer had space to arrive on its own.
If you ship products, ship products well—Shopify’s native account area is enough, and getting better every quarter you ignore it. If you build a relationship your customers live inside, build the room they live in, and accept the contract that comes with it. The two mistakes look nothing alike from the inside and completely alike on the agenda, where they both get the slot before the door. The real mistake is the one underneath both of them: choosing the architecture before you have decided which business you are running.
The account page will tell you which business that is. You only have to let the meeting run long enough to ask it.