When a company decides to move into e-commerce, the first fork in the road is always the same: do we build the store from scratch or use a template? The question sounds simple, but the wrong answer can cost a great deal of money — and a great deal of wasted time — in the years that follow. In this article we analyse both models without beating around the bush: what each one offers, when each option makes sense, and what the most common mistakes SMEs make when choosing.
What is a template-based online store and what is a custom store?
A template-based online store (or theme-based store) is an e-commerce project built on a predefined design and the standard functionality of a platform such as Shopify, WooCommerce or PrestaShop. The business owner installs the theme, configures the products and starts selling. Time to market is short and the barrier to entry is low.
A custom online store is a solution designed and programmed specifically for the processes, catalogue and business objectives of the company. It may be built on a framework or base platform — Laravel, Symfony, Next.js, Magento, etc. — or developed entirely from scratch. The result is a system that fits the business logic precisely, without the constraints imposed by a generic theme.
The distinction is not purely technical: it has direct consequences on page load speed, conversion rate, the ability to integrate with the company's ERP, logistics system or CRM, and the total long-term cost.
When a template makes sense
Templates are a valid solution in specific scenarios. They are not an inferior option by definition; they become an inadequate option when used outside their natural context.
- Small, stable catalogue: fewer than 500 SKUs with limited variants. The template covers the product lifecycle without strain.
- Very tight initial budget: when the goal is to validate the channel before investing in custom development, a template allows you to launch with minimal outlay.
- Standard sales process: if the checkout, payment methods and shipping logic require no specific customisation, the template works well.
- Teams without internal technical resources: managing the catalogue, orders and promotions on platforms like Shopify is accessible for non-technical profiles.
- Very short launch window: when a seasonal campaign, trade fair or event demands a digital presence within weeks, a template is the only viable option.
When the template falls short
The problem does not appear on launch day. It appears six to eighteen months later, when the business grows and the platform starts to creak. These are the most common symptoms:
- The catalogue grows beyond 2,000–3,000 SKUs with complex variants (size, colour, bundle, personalisation) and performance drops.
- Integration with the ERP or WMS requires custom development that the platform does not natively support, resulting in expensive patches.
- Pricing, stock or business rules (volume discounts, B2B tariffs, customer-specific pricing) cannot be implemented without paid plugins whose combination creates conflicts.
- Page load speed — a direct conversion factor — deteriorates because the theme includes code that is unnecessary for the specific use case.
- The company wants to sell in multiple languages, currencies or markets with different tax rules, and the template architecture does not support this without friction.
Direct comparison: template vs custom store
| Criterion | Template (Shopify / WooCommerce / PrestaShop) | Custom development |
|---|---|---|
| Time to launch | 2–8 weeks | 3–6 months (average project) |
| Initial investment | Low to medium | Medium to high |
| Total cost over 3 years | Medium to high (licences, plugins, patches) | Medium to low if the project is well planned |
| Performance and speed | Variable; depends on the theme and active plugins | Optimal: only the code that is needed |
| Adaptation to own processes | Limited; processes must be adapted to the software | Total; the software adapts to the process |
| ERP / CRM / WMS integration | Via generic connectors or middleware | Direct, custom integration |
| Catalogue scalability | Limited beyond tens of thousands of SKUs | High; architecture designed for the real volume |
| Technical SEO | Theme-dependent; bloated code is frequent | Full control over structure, URLs and performance |
| Third-party dependency | High (platform, plugins, paid themes) | Low; the code is owned by the company |
| Maintenance | Frequent updates, risk of incompatibilities | Controlled; changes only when necessary |
| B2B suitability | Low without specific paid plugins | High; native B2B tariffs, access controls and workflows |
The real cost: why a template can end up more expensive
One of the most common mistakes when making this decision is comparing only the initial outlay. The template appears cheaper on day one, but analysing the total cost of ownership (TCO) over three or five years frequently changes the outcome.
On subscription-based platforms like Shopify, you need to add the monthly plan fee, transaction fees when you do not use the platform's own payment gateway, the cost of the premium theme and the plugins needed to cover features that would be included from the outset in a custom development. A typical plugin stack for a mid-size Shopify store can add between €300 and €600 per month in licence fees, according to 2025 Shopify App Market data. In WooCommerce, the cost is not subscription-based but maintenance-based: frequent updates to the core, themes and plugins are the main source of incidents.
Then there are corrective developments: when the business needs a feature the template does not support, custom modules layered on top of the codebase generate accumulated technical debt. Over time, each new feature becomes more expensive to implement because the developer has to fight against the existing architecture rather than building on a clean foundation.
In a well-planned custom online store project, the initial cost is higher, but evolution is more predictable: no licence surprises, no plugin incompatibilities, and each change has a cost proportional to its real complexity — not to the effort of working around platform limitations.
Load speed and conversion: the real impact
Site performance is one of the most decisive factors in e-commerce and one of the most undervalued at the decision stage. Data from Google and the industry is consistent: every additional second of load time on a product page reduces the conversion rate significantly. The most cited studies point to drops of around 7% for each additional second of delay on mobile devices.
WordPress/WooCommerce templates and Shopify themes load CSS, JavaScript and fonts that are not always used on every page. The result is a page weight greater than necessary and a higher time to first byte (TTFB). In a custom development, the front end is built with only the code each page needs, and the server architecture is sized for the project's real traffic.
The SEO impact is equally relevant. Since 2021, Google has incorporated Core Web Vitals metrics (LCP, INP, CLS) as a ranking factor. A slow site does not just convert less — it also ranks lower. Custom projects have a structural advantage here because the development team controls the loading architecture, asset size and caching strategy from day one.
Integration with ERP, CRM and logistics systems
For many industrial SMEs or distributors, the biggest bottleneck is not the user experience in the store but the integration with internal systems. Synchronising stock in real time with the ERP, routing orders directly to the logistics system without manual intervention, or applying the specific tariffs of each B2B customer are requirements that generic templates cover only partially or at high cost.
Market connectors (integration plugins for Sage, Holded, Odoo, Dynamics 365…) offer basic synchronisations, but when the business logic is complex — multiple warehouses, batches with expiry dates, prices negotiated by customer or by volume — generic connectors are not sufficient and end up generating stock errors, duplicate orders or fulfilment delays.
In a custom development, the integration layer is designed from the outset for the exact API of the company's ERP. The result is a robust bidirectional synchronisation that eliminates manual data entry and reduces operational errors. At Summum Sistemas we have been solving this type of integration for SMEs in Castilla y León and the Canary Islands since 2007, with projects covering everything from sector-specific ERPs to third-party logistics platforms.
B2B: the case where a template is almost never enough
If the e-commerce is aimed at business customers (B2B), the limitations of templates become critical. A B2B portal needs, as a minimum:
- Customer registration with manual or automatic approval based on business criteria.
- Differentiated pricing by customer, customer group or purchase volume.
- Orders with the customer's own purchase order reference.
- Credit limits and deferred payment terms (30, 60, 90 days).
- Selective catalogue visibility: not all customers see all products.
- Order history and download of delivery notes and invoices in the private area.
Shopify has B2B modules in its Plus plan, which has a monthly cost far above the standard plans. WooCommerce requires paid plugins for customer-specific pricing and payment terms. In both cases, advanced features push up the monthly cost and technical complexity to the point where the initial cost advantage over custom development disappears.
If your company sells to other businesses and needs a robust B2B order portal, we also recommend reading our service page for B2B customer portal, where we explain which features are essential and how they integrate with the ERP.
How to make the right decision
There is no universal answer. The choice between a template and custom development depends on four variables that every company should analyse before commissioning the project:
- Catalogue volume and variant complexity: more than 2,000 SKUs or complex variants tip the balance towards custom development.
- Need for integration with internal systems: if there is an active ERP with proprietary processes, custom integration is almost always more efficient in the long run.
- B2C or B2B business model: pure or mixed B2B requires features that templates do not cover well without significant additional cost.
- Project time horizon: if the digital channel is strategic and the company plans to scale, custom development pays back the investment in two or three years. If the goal is to validate the market in six months, the template is the right tool.
A frequent mistake is starting with a template with the intention of "migrating later". Migrating an established store — with catalogue, customers, order history and SEO rankings — is a complex and costly project. If the strategic horizon points to custom, it is more efficient to plan for it from the outset.
Frequently asked questions
Is it possible to start with a template and migrate to custom without losing SEO?
Yes, but it requires careful planning. The migration must maintain the URL structure, implement 301 redirects for any URLs that change, transfer all metadata and correctly manage the sitemap file. If done well, Google reassigns authority to the new URLs within a few weeks. If done badly — without redirects or by changing the entire structure at once — years of accumulated rankings can be lost. It is advisable not to migrate during peak sales season, and to monitor organic performance for the two months following the migration.
What base platform is used in a custom development?
It depends on the project. For stores with complex catalogues and intensive integration needs, frameworks such as Laravel or Symfony provide the necessary flexibility. For projects that need front-end speed and strong search performance, headless architectures with Next.js or Nuxt.js as the front end and a custom back-end API are a solid option. Magento (Adobe Commerce) remains a reference for high-volume catalogues with advanced B2B requirements, although its implementation and maintenance curve is steep. The choice of technology should respond to business requirements, not to the development team's preferences.
What happens if the provider who built the custom store disappears?
This is a legitimate risk that must be managed from the contract stage. The correct approach is for the client to own the source code, for the project to be documented, and for the repository to be accessible to the client at all times. With those conditions in place, any other team can take over maintenance. At Summum Sistemas we always deliver the complete source code to the client, with technical documentation and access to the repository. The company's software cannot depend on the continuity of a single supplier.
Are Shopify or WooCommerce templates bad for SEO?
They are not inherently bad, but they have structural limitations. The code in popular themes frequently includes JavaScript and CSS that loads on every page even when not used, which penalises LCP (Largest Contentful Paint) and INP (Interaction to Next Paint) — two of the three Core Web Vitals metrics. Well-optimised themes with few plugin dependencies can perform reasonably well in terms of technical SEO, but they rarely reach the levels of a custom development where performance is engineered from day one. If organic SEO is an important acquisition channel, this factor should weigh in the decision.