A three-level framework for deciding where to build custom in e-commerce, and where not to.
Two years ago we published an article defending custom web development over templates. It argued that templates solve things fast and cheap, but rarely deliver a scalable, distinctive experience. Today we wouldn't say the same thing.
Not because the argument was wrong. Because it was framed as a question that, in practice, almost no real project answers in a binary way. The conversation we have today with product brands, especially on Shopify, looks more like this: the brand is visually strong, the catalog is small, photography carries most of the communication weight, there's a budget but it isn't unlimited, and there's a launch date tied to the commercial season. In that scenario, “custom or template” is a question that doesn't help you decide anything.
The useful question is a different one: where to concentrate engineering and design effort so it generates a return, and where to accept what the platform already solved.
When a brand says “I don't want it to look like a template,” they're almost always thinking about the homepage. The hero, the typography, the transition on the landing page. That's understandable: it's the first thing they see, and what they show in the approval meeting.
But usability data points elsewhere. Baymard's research on leading sites in the U.S. and Europe shows that barely half achieve decent or good performance on the product page on desktop, and the figure drops even further on mobile. On the homepage and category navigation, most of the sites evaluated fall between mediocre and poor.
Even more telling is where the failures concentrate within the product page. Baymard has documented that the average website performs reasonably well exactly where templates already have things solved: image galleries, product variants, basic descriptions. The serious failures show up in technical specs, shipping and returns information, reviews, the buying section, and cross-navigation between products.
In other words: sites fail in the areas where the brand needs to say something specific about its product, its promise, and its operations. Those are exactly the areas no template can anticipate, because they depend on the business, not the industry.
And those are, almost always, the last ones to get attention.
Instead of the dichotomy, it's worth thinking in a gradient. At Contra we work with three levels:
A theme is installed, the color and typography system is applied, sections are arranged. It works for validating a product, for conventional catalogs, for brands where differentiation isn't yet a commercial advantage. It's a legitimate decision, and often the right one.
The theme provides the structure, checkout, cart logic, and maintenance. On top of that, specific components get built: a product page that handles sizing and returns the way the brand actually operates, a narrative module explaining materials or process, a configurator, a social proof section that's designed rather than pulled from a generic app.
The entire frontend is built from scratch on top of the platform's commerce infrastructure. It makes sense when the experience itself is the competitive edge, when volume justifies
optimizing every millisecond, or when there's operational complexity no template accounts for.
A recent industry analysis describes the middle tier as the most underbuilt position in e commerce, and that matches what we see: it's where more brands should be, and where fewer actually are, because the market keeps selling the decision as binary.
Three questions organize the conversation well.
If the brand sells resort wear and the theme doesn't allow showing fabric drape, real sizing, or an international returns policy, there's a concrete conversion loss right there. That justifies development. An animated hero, on the other hand, rarely does.
H3: What moment in the narrative needs a design the template doesn't have?
Almost every brand with a premium positioning has two or three moments where it needs to breathe differently: entering a collection, the origin story, the transition between categories. Identifying those moments and building them well creates more brand perception than redesigning the entire site.
This is the hidden cost almost nobody budgets for. The template route tends to fill its gaps by installing third-party apps, and each one loads its own scripts. The site starts out fast and degrades over the first year, until the team concludes the theme was bad.
The theme wasn't bad. The accumulation was. Replacing three or four apps with custom components is usually the development investment with the best return in the whole project.
There are very convenient numbers circulating online: that custom development converts 25% to 50% better, that it loads 40% to 60% faster. Almost all of them come from studies published by agencies that sell custom development. We sell custom development too.
We recommend treating those numbers with the skepticism they deserve, including our own from two years ago. Speed and usability do affect conversion, that's well documented by independent sources. But the range of improvement depends on where you're starting from, your traffic, your average order value, and your category. Anyone who promises you a percentage before looking at your analytics is selling, not advising.
The honest way to estimate the return is the other way around: first look at where on the site customers are dropping off, how much that's costing the business, and how much it would cost to fix. If the math doesn't work out, it's not worth doing.
In 2024 we defended custom development as a category. Today we defend something more specific: custom development applied with judgment, on top of a foundation that already solved what isn't worth solving again.
Nobody needs to build a cart from scratch. Almost nobody needs to build a collection grid from scratch. What does need to be built from scratch is whatever the brand says that no one else can say, and whatever moment decides whether the customer buys or leaves.
A site doesn't become premium because of how much custom code it has. It becomes premium because every visible decision was made by someone, rather than inherited by default. That can be achieved on a limited budget, as long as the budget is spent in the right place.
Contra Studio designs and builds digital platforms for brands across Latin America and the United States. If you're deciding where to focus the effort on your next project, let's talk.
It depends on where the experience is actually failing. A template already handles the cart, checkout, and product gallery well; what it almost never handles is information specific to the business, like real sizing, a returns policy, or brand moments. The useful question isn't “which one to choose” but where to concentrate the development effort.
Figures like “converts 25-50% better” usually come from agencies that sell custom development, including this one. The real improvement depends on your starting point, your traffic, and your category. The honest way to estimate it is to look at where on the site people are dropping off and how much that's costing the business, not to start from a generic percentage.
When the experience itself is the competitive edge, when volume justifies optimizing every detail, or when there's operational complexity (sizing, returns, configurators) that no template accounts for. For conventional catalogs or brands still validating their product, a well configured template is usually the right call.
It's almost never the theme's fault. The most common pattern is that the store keeps filling gaps with third-party apps, and each one loads its own scripts. The site starts fast and degrades over the first year, until it looks like “the theme is bad” when it's really the buildup of apps.
According to Baymard's research, sites tend to perform reasonably well on what the template already has solved, like the gallery and product variants, but they fail on technical specs, shipping and returns, reviews, and cross-navigation between products, exactly the areas where the brand has to say something specific about itself.
