After three years of Shopify Plus builds — stores doing anywhere from six figures to nine figures a year — we have a clear picture of which architectural decisions aged well and which ones we've had to explain to the next agency hired to clean up our work. This is the honest version of that list.
The biggest regret: going headless before the business justified it. We did this twice in the early years, both times at the client's request, both times with a stack that was genuinely exciting to build. Hydrogen on Vercel, Sanity, Algolia, the works. Both stores are now back on a Liquid theme. The editorial teams couldn't keep up with two systems. The performance gains were real but the operational cost outweighed them at that revenue level. Headless is the right call for the right business — we just applied it too early in two cases where a well-optimised Liquid build would have outperformed it on the metrics that actually moved the needle.
The second regret: letting the app stack grow unchecked. Shopify's app ecosystem is a productivity trap. Every app solves a real problem. Collectively, twenty apps create a performance problem, a data ownership problem, and a maintenance problem that compounds with every Shopify major release. Our rule now is that every new app requires removing an existing one or justifying why the custom-built equivalent would cost more over three years. That constraint has saved more client budgets than any other single practice.
Third: metafield schemas designed in the first sprint and never revisited. We've inherited stores with metafield structures that made sense when the catalogue had 50 SKUs and make no sense at 5,000. Migrating metafields on a live store without breaking storefronts, third-party tools, and automations is miserable work. We now treat the metafield schema as a proper data model with a review gate before every new addition, and we document deprecation paths from day one.
Fourth: deferring checkout extensibility decisions. Before Checkout Extensibility, the answer was often 'we'll deal with checkout later.' Later is now. Stores still running checkout.liquid are on a forced migration timeline, and the ones with the most custom checkout logic are the most painful to migrate. Every build we start now includes a checkout extensibility audit in week one, even if no customisation is planned — because something always comes up.
Fifth: monolithic theme files. Sections that do too much. JavaScript embedded inline rather than loaded as modules. CSS that lives in one 4,000-line file because the original developer didn't want to deal with Webpack. We've inherited all of these. The time savings from not setting up a proper build pipeline in the first sprint compound into weeks of refactoring later. Dawn-based themes with a proper module structure have made this easier, but the discipline has to be enforced from the start.
Most of these regrets share a root cause: architectural decisions made in the first sprint that felt fast and practical at the time. The stores that aged well were the ones where we spent two weeks in discovery arguing about data models and deployment pipelines before writing a single Liquid line. The ones we regret were the ones where we started building on day one because the client had a launch date and we wanted to be helpful. Being helpful in week one and painful in year two is not actually helpful.
Written by the brainiac/studio team. We publish original work from the engineers, designers, and marketers who do the work — never outsourced to a content shop.