Ecommerce Website Design — Ready-Made Template or a Custom Build

Ecommerce website design usually comes down to one decision at the start for most small sellers: a ready-made template, or a project built from scratch. The data on the template market and on platform performance gives a less black-and-white answer than the usual advice — "always invest in a custom design" on one side, "a template is enough for everyone" on the other: a template is a sensible starting point for most small stores, and a custom build starts to pay off once the template genuinely blocks a specific business process or a performance number you can measure. This article covers design and page structure only — law, platform choice, cost and SEO already have their own, more detailed articles on this site, which we link to here instead of repeating them.

Ecommerce website design: what has to exist regardless of the look

Before you touch the homepage layout, three things need to exist no matter what the store looks like:

• Terms and conditions — under the EU E-Commerce Directive (2000/31/EC, Art. 10(3)), contract terms and general conditions given to the customer "must be made available in a way that allows him to store and reproduce them" — in practice, a page or PDF the customer can save or print before ordering. In Poland this is Art. 8(1)(2) of the Act on providing services by electronic means (ustawa o świadczeniu usług drogą elektroniczną): the seller makes the terms available free of charge before the contract is concluded, in a way that lets the customer obtain, reproduce and store them — and under Art. 8(2) the customer is not bound by terms that were not made available that way. What those terms may and may not say is a matter of consumer law.
• Pre-contract information — the Consumer Rights Directive (2011/83/EU, Art. 6(1)), implemented in Poland by Art. 12(1) of the Consumer Rights Act (ustawa o prawach konsumenta), requires telling the customer, "in a clear and comprehensible manner," the full set of information it lists, including how and when they can withdraw from the contract. For physical products, the GPSR (Regulation (EU) 2023/988, Art. 19, applicable from 13 December 2024) adds its own duty: manufacturer details — and, where the manufacturer isn't based in the EU, the details of an EU-based responsible person — product identification (including a picture) and any warnings or safety information — and the offer itself has to "clearly and visibly indicate" all of it.
• A returns page — the rule itself (14 days to withdraw without giving a reason) and the mechanics of refunding the payment have their own, much more detailed article: returns and legal guarantee. Here it's enough that such a page exists and is easy to find from the footer.

There's one more page that's easy to forget when designing a site: a privacy and cookie policy, separate from the terms and conditions, because the GDPR requires telling people what personal data the store collects and why — whether it collects data only to fulfil orders or also for analytics and marketing. Consent for cookies and similar trackers comes on top of that, from Art. 399 of the Electronic Communications Law (Prawo komunikacji elektronicznej), which requires prior information about the purpose and the user's consent. Its exact content depends on which tracking technologies are actually switched on (Consent Mode, ad pixels) — that's a topic for its own article, not this one.

We cover the full picture of legal duties when setting up a store, with specific dates (the European Accessibility Act, the Omnibus Directive, the GPSR), in how to set up an online store — this article points there instead of repeating the same directives. The product page itself carries its own separate set of duties (GPSR data, photos, pricing during promotions), covered in our article on the product page.

Template: what it gives you, and where its limits are

A ready-made template solves, in a few minutes, what a from-scratch build takes weeks to do: the homepage layout, product cards, cart and checkout, responsiveness, baseline accessibility. The Shopify Theme Store has its own browsable collection of free themes (24 on the day of reading), and its 1,278 paid themes were priced from $100 to $500 (read 6 October 2026) — that's one reading of a live marketplace, not an official price list Shopify announces, because a theme marketplace changes its range and assortment all the time. WooCommerce and PrestaShop run on the same mechanism — free themes in the platform's own repository, paid themes in separate marketplaces — but a current, specific price range for those two platforms wasn't part of this research, so we don't give a number for them here.

The Polish SaaS platforms work the same way. Shoper runs a catalogue of graphic templates where free and paid themes sit side by side: across the four catalogue pages there are over 60 templates, more than 20 of them free, and the paid ones cost from PLN 499 to 3,499 net (read 6 October 2026). Shoper states that payment for a chosen theme is one-off and that you use it "without any time limits or additional costs" (translated). IdoSell offers 13 free templates, "available free of charge to all Merchants" according to its blog post of 14 April 2026 (IdoSell blog), chosen from the template gallery in the admin panel. The platform subscription is a separate cost.

The template's limit is functional, not just visual: a good template handles a typical buying process, but if your store has an unusual one — a product configurator, a complex B2B model with per-customer pricing, an integration the template never anticipated — that's exactly where the template starts getting in the way instead of helping. What the whole store costs, not just the theme, is broken down in ecommerce website cost, and specific platforms and their pricing are compared in our ecommerce platform comparison — if you're still choosing a platform, start there, not here.

Template vs performance: the technical debt you can't see

A universal template has to serve very different stores at once, so it may run a visual page builder, a backward-compatibility layer and room for any number of third-party apps or plugins, all at the same time — that's the mechanism through which a template can hurt Core Web Vitals, LCP especially, before you've even added your own content. The HTTP Archive Web Almanac 2025 (the "Ecommerce" chapter, data from July 2025, published January 2026) measures the share of sites with a "good" Core Web Vitals result — LCP, INP and CLS all passing at the 75th percentile — by platform: Shopify 76% on mobile and 76% on desktop, PrestaShop 50% on mobile and 54% on desktop, WooCommerce 35% on mobile and 33% on desktop. The chapter calls LCP "the biggest differentiator" between platforms, and for WooCommerce that's exactly where it struggles (45% good results on desktop, 39% on mobile), while INP and CLS come out better (88% and 85% good on mobile; on desktop, INP 99% but CLS only 68%).

Worth keeping next to these numbers: this is global, platform-wide data — every detected site on a given engine, with no country breakdown — not an assessment of any specific theme or installation. A well-configured WooCommerce store, stripped of unnecessary plugins, can score better than its platform's average, and a neglected Shopify store loaded with dozens of apps can score worse. The numbers show a gap between platforms, not its cause in any one store — "the more unconsolidated scripts and plugins on a page, the harder it is to get a good LCP" is our reading of the mechanism, not a measured result, and it isn't a verdict on any specific platform.

The previous edition of the same Web Almanac chapter shows that a weak platform score isn't a permanent verdict — it's a state that changes from edition to edition. The 2024 edition (earlier data, published 2024-11-11) recorded WooCommerce's LCP result at "just 34%" on mobile — lower, even, than the 39% in the 2025 edition — but over the same period other platforms improved sharply (mobile data): Tiendanube went from 28% good LCP results in 2022 to 61% in 2024, and Squarespace from 33% to 60% of sites with a good overall Core Web Vitals result in the same window. The practical takeaway: template performance isn't a fixed trait of an engine forever — a weak LCP score two years ago doesn't mean a weak score today, and the reverse holds too.

If the template is blocking a process or a performance number you're checking with our website speed test, and fixes within the template itself no longer help, the next step is usually not "a different template" but a different architecture — see the next section.

Custom build: when it's worth it

A from-scratch build makes sense when a specific process or a specific performance metric matters more than how fast you can launch — not as the default choice "because it looks better." It's a decision that costs more time and work than configuring a template, so it's worth making on the basis of a specific, named constraint (this configurator doesn't work, this integration doesn't exist, this Core Web Vitals result isn't improving despite optimisation), not on a general feeling that "the template looks too generic."

The most radical form of a custom build is headless — decoupling the front end (built, for example, on Next.js) from the ecommerce platform's engine, which then becomes just a backend for data and orders. That architecture gives full control over what actually reaches the browser — and so over performance — at the cost of some things a template gave you for free: ready-made integrations with apps from the platform's own marketplace, security updates handled by the engine's vendor, and a simple setup for anyone without their own development team. That trade-off — full control at the cost of convenience and vendor-managed maintenance — is the practical reason headless pays off only once a template genuinely can't keep up, not as a default upgrade. When that step pays off and when it's overkill is covered separately in our article on headless commerce; how to measure and improve the Core Web Vitals metrics themselves — whether you stay on a template or go headless — is in Core Web Vitals for ecommerce.

Homepage and navigation structure

Whether the page is built by a template or a custom project, a few structural elements are worth having in every store, because they follow from the logic of the buying journey, not from fashion:

• A value proposition visible without scrolling — the customer needs to know right away what they're buying and from whom, with no need to scroll the homepage.
• Visible category navigation — a stable, predictable category structure, available from every subpage, not just the homepage.
• A visible search field — placed in a fixed, obvious spot in the header; what the search itself should do and how to measure it is covered in our article on ecommerce site search.
• Trust signals near the top of the page — information about secure payment, the returns policy and real customer reviews, not tucked away in the footer.
• A footer with legal links — terms and conditions, privacy policy, contact details and a returns page, always in the same, predictable place.

This set of sources didn't turn up a specific, named UX study on homepage navigation for online stores — the list above describes a mechanism, not a quote from research, and it's worth treating as a starting point for your own usability tests, not as a closed, verified benchmark. In practice, none of these points is unique to one type of build — a template and a custom project deliver the same list, just with a different cost of change: in a template you reorder sections through the theme editor, in a custom build through code — but the list of requirements itself doesn't change. If the page also has filters and product listings, their UX and their effect on SEO (faceted navigation specifically) are their own, separate topic — the UX side in our article on site search, the technical-SEO side in our ecommerce SEO guide.

Phone vs desktop — two separate measurements, not one

Two different mobile measurements talk about two different things, and shouldn't be added together. StatCounter for Poland, September 2026: desktop 56.03%, mobile 43.36%, tablet 0.62% of page views in StatCounter's own panel (read 5 October 2026) — that's browsing traffic in general, not shopping specifically, and it's not a census of the full population, only data from one company's own panel.

A second kind of measurement — which device someone actually completes a purchase on, as opposed to which device they browse on in general — asks a different question on a different sample. For Poland, the Gemius "E-commerce w Polsce 2026" report answers it: in a CAWI survey (14–22 July 2026, 1,874 internet users, percentages among online buyers), 58% of respondents finish their purchases on a phone, 44% of them in an app, and 35% on a computer. That is a different population (buyers, not all users) and a different question (the device on which the customer completes the purchase, not a share of traffic). The practical conclusion from both sources: the page has to work well on both the phone and the desktop, and "well" doesn't mean "identically" — check the checkout and the forms on a real phone, because most buyers finish the transaction there.

Accessibility in a template — baseline checks

The digital accessibility duty for online stores comes from the European Accessibility Act (Directive (EU) 2019/882), which covers e-commerce services from 28 June 2025, with a micro-enterprise exemption for services (fewer than 10 staff and annual turnover or balance sheet total not exceeding €2 million, Art. 4(5) with the definition in Art. 3(23)). In Poland the duty comes from the act on ensuring accessibility requirements for certain products and services (Dz.U. 2024, item 731), which excludes services provided by micro-enterprises in its Art. 4(1). Who supervises compliance and how penalties are calculated is covered in the ecommerce UX hub, together with the rest of the section's topics. Here's just the list of baseline things worth checking in the template itself, before you move to a full accessibility audit. The WCAG 2.2 success criteria are given in brackets (WCAG 2.2, W3C Recommendation of 12 December 2024). Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1 — not the other way round.

• Text contrast — at least 4.5:1 for normal text and 3:1 for large text (1.4.3), especially in colour variants of the template that the theme's author never tested for this.
• Semantic HTML — headings in a logical hierarchy, buttons as <button>, not a <div> with a click handler (1.3.1, 4.1.2).
• Alt text on product photos, not only on the store's main hero image (1.1.1).
• Full keyboard support — you can get through navigation, filters and the order form without a mouse (2.1.1).
• A visible focus state on links, buttons and form fields, so someone navigating by keyboard can see where they currently are (2.4.7).
• Field labels — a label attached to every order-form field, not just a placeholder that disappears the moment you click into the field (3.3.2).
• Touch target size — at least 24 × 24 CSS pixels, or enough spacing around smaller targets (2.5.8), which matters for variant and quantity buttons on a phone.

How to choose — a checklist

• You've checked whether a typical, ready-made template actually handles your sales process (configurators, B2B pricing, unusual integrations), instead of assuming it will "adapt somehow."
• You have terms and conditions, the required pre-contract information and a returns page visible from every subpage, not only the homepage.
• You've measured the Core Web Vitals of your specific template installation (not the platform average) before deciding to move to a custom build.
• You've tested checkout and forms for real on a phone, not only by resizing a browser window on a desktop.
• Navigation, search and trust signals are visible without scrolling, and the footer has the full set of legal links.
• You've gone through the baseline accessibility checks above before deciding a template "is enough."

If you'd rather make this decision together with someone who'll assess your specific template and your specific installation, not just a platform average, talk to us — that's also one of the items on the ecommerce UX checklist.