E-commerce architecture matters more than store design because the decisions that drive revenue and operating cost (which platform you build on, how the catalogue and URLs are structured, how checkout and payments work, and how orders and stock flow to your ERP) are fixed before a designer opens a file. Good design cannot rescue a store whose structure works against buyers, search engines or the warehouse.
Architecture decisions that determine outcomes
Six decisions shape an online store's results more than any visual choice: platform, catalogue taxonomy, URL structure, checkout flow, payment configuration and back-office integration. Each is made either explicitly, with a documented rationale, or implicitly, by whoever happens to set up the first product. The second route is how stores end up being rebuilt within a few years.
The practical difference is cost of change. A colour palette or homepage layout can be revised in days. Changing platform, re-structuring thousands of product URLs, or retrofitting an ERP integration means data migration, redirects, retesting and lost search visibility. That is why these questions belong in the first workshop, not the last.
| Decision | What it controls | Cost of getting it wrong later |
|---|---|---|
| Platform | Checkout flexibility, extension model, hosting, data access | Full re-platform and data migration |
| Catalogue taxonomy | Navigation, on-site search, filters, reporting | Re-categorising every SKU; broken reports |
| URL structure | Crawling, indexing, canonical signals, shareability | Mass redirects and temporary ranking loss |
| Checkout flow | Conversion, guest purchase, cost transparency | Lost orders until rebuilt |
| Payments | Which buyers can pay, settlement, reconciliation | Abandoned carts; manual reconciliation |
| ERP and inventory integration | Stock accuracy, fulfilment, finance posting | Overselling and manual re-keying that grows with volume |
Platform selection is not a commodity decision
Shopify and WooCommerce are both capable platforms, but they trade speed against control, so the right choice depends on how much of the checkout and data layer you need to own. Shopify's hosted, opinionated structure makes it faster to launch and removes server maintenance; WooCommerce, which runs on WordPress, allows deeper customisation but requires disciplined governance to avoid accumulating technical debt.
Two current platform facts illustrate the trade-off. On Shopify, checkout customisation is constrained by design: checkout.liquid is now unsupported for the Information, Shipping and Payment steps, and it was sunset for the Thank you and Order status pages on 28 August 2025, so changes must be built as checkout extensions. On WooCommerce, order data architecture has changed: from version 8.2 (October 2023), High-Performance Order Storage moves orders into dedicated tables and is enabled by default for new installations, which matters for any plugin or integration that reads orders directly from the database.
| Factor | Shopify | WooCommerce |
|---|---|---|
| Hosting and maintenance | Hosted by Shopify | Self-hosted; you own updates, security and backups |
| Checkout customisation | Through checkout extensions only; checkout.liquid unsupported for core steps (Shopify.dev) | Fully modifiable in code, with matching testing burden |
| Data model | Accessed through Shopify's APIs | Direct database access; HPOS order tables by default on new installs (WooCommerce) |
| Speed to launch | Faster | Slower; more configuration |
| Main risk | Hitting platform limits on bespoke flows | Plugin sprawl and technical debt without governance |
A useful test: list the three checkout or pricing behaviours your business cannot live without (for example B2B price lists, deposits, or delivery-slot booking) and confirm each is supported natively, by a maintained app or plugin, or by custom code you are prepared to own. If the answer is "custom code" on a platform that restricts it, choose differently before design starts.
The catalogue architecture problem
Catalogue structure determines navigation, on-site search, filters, SEO and reporting, so it has to be designed for the product range you expect to carry, not only today's inventory. Catalogues built without taxonomy planning become hard to maintain as the SKU count grows, and categories added reactively produce inconsistent URLs that confuse both customers and search engines.
Good catalogue architecture separates three things that are often mixed together:
- Categories: the stable hierarchy shoppers browse (for example Kitchen > Cookware > Frying pans).
- Attributes: filterable properties such as size, colour, material or brand, defined once with controlled values.
- Variants: purchasable combinations of attributes, each with its own SKU, stock and price.
As a working rule, Namtech plans the taxonomy for the range expected about two years ahead (Namtech guidance). In practice that means agreeing attribute names and allowed values before import, deciding which attributes become filters, and mapping categories to the reporting groups finance already uses in the ERP.
URL structure and search visibility
URL structure is an architectural decision because it determines how efficiently search engines crawl and understand a catalogue, and it is expensive to change after launch. Google's guidance on designing a URL structure for ecommerce sites recommends long-term, persistent URLs, a separate URL for each product variant (as a path segment such as /t-shirt/green or a query parameter such as /t-shirt?color=green), and a canonical URL that omits optional variant parameters.
Filters need the same planning. Google's documentation on faceted navigation warns that the common parameter-based implementation can generate infinite URL spaces, causing overcrawling and slower discovery of new, useful pages. Decide early which filter combinations deserve indexable landing pages and which should stay out of the crawl.
Product data structure also feeds search features. Google's product structured data distinguishes merchant listings (pages where people can buy) from product snippets, and the required properties come from the catalogue: price, availability, variants, shipping and return policies. If those fields are not modelled cleanly, the markup cannot be generated reliably.
Checkout conversion is an architecture problem
Most avoidable cart abandonment comes from how checkout is structured, not how it looks. Baymard Institute calculates an average documented cart abandonment rate of 70.22%. In its survey of US shoppers, after excluding those "just browsing", the leading reasons were structural:
| Reason for abandonment (Baymard, US shoppers) | Share | Architectural response |
|---|---|---|
| Extra costs too high (shipping, tax, fees) | 40% | Calculate shipping and fees early; show totals before checkout |
| Didn't trust the site with card information | 19% | Hosted or tokenised payment fields; recognised payment brands |
| Site wanted me to create an account | 18% | Guest checkout as default; optional account after purchase |
| Too long or complicated checkout | 17% | Fewer form elements; address autocomplete |
| Website had errors or crashed | 17% | Load testing; monitored integrations |
| Not enough payment methods | 9% | Local methods configured at gateway level |
Source for all shares: Baymard Institute, Cart Abandonment Rate Statistics (list last updated 22 September 2025).
Form length is the clearest example. Baymard reports that an ideal checkout flow can be as short as 12–14 form elements, yet the average US checkout shows 23.48 by default. Removing fields is not a styling task: it depends on whether the platform, the payment gateway and the ERP can work with less data, which is decided in the architecture.
Speed is also structural. Google's Core Web Vitals set targets of Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile of page loads. Hosting, image pipelines, third-party scripts and app or plugin count drive these numbers far more than visual design does.
Payments for Singapore buyers
Payment architecture determines which customers can complete a purchase, so the methods your buyers use must be supported by your platform and gateway combination before launch. For Singapore stores this usually means cards plus PayNow. According to The Association of Banks in Singapore, PayNow lets customers of participating banks and major payment institutions send Singapore dollar funds instantly using a mobile number, NRIC/FIN or Virtual Payment Address, and businesses can receive funds by linking their UEN through PayNow Corporate.
Check three things at selection stage: whether the gateway supports the methods natively on your chosen platform, how payment confirmations reach the order system (webhooks rather than manual matching), and how settlements are reconciled in accounting.
ERP integration: the operational multiplier
A store without inventory and order integration creates manual work that grows in step with order volume. Stock levels managed in two systems, orders re-keyed into accounting, and fulfilment triggered by spreadsheet are all symptoms of the same cause: the store was built without integration architecture.
Designing integration from the start means agreeing, before build:
- System of record for each data type: products and prices, stock, customers, orders and invoices.
- Sync direction and timing: for example stock pushed from ERP to store on change, orders pulled into the ERP as they are paid.
- Identifiers: one SKU scheme shared by both systems, so variants map one-to-one.
- Failure handling: retries, alerts and a visible queue when a sync fails, so oversells and missing orders are caught the same day.
Our article on ERP and e-commerce integration covers the integration patterns in more detail, and Namtech's Odoo ERP implementation service covers the back-office side.
A pre-design architecture checklist
Before any design work starts, the following should be written down and signed off by the business owner:
| Area | Question to answer in writing |
|---|---|
| Platform | Which non-negotiable checkout, pricing and B2B behaviours must it support, and how? |
| Catalogue | What are the categories, attributes, allowed values and variant rules for the expected range? |
| URLs | What patterns will product, category and variant URLs follow, and which filters are indexable? |
| Checkout | Is guest checkout the default, and are all costs shown before the payment step? |
| Payments | Which methods (cards, PayNow, others) are needed, and how are confirmations and settlements reconciled? |
| Performance | How will Core Web Vitals be measured and kept within Google's thresholds after launch? |
| Integration | Which system owns each data type, in which direction does data sync, and who is alerted on failure? |
Namtech Pte Ltd, a Singapore AI transformation consultancy, runs this architecture phase as part of its e-commerce development service, published from SGD 12,000 over 8–14 weeks, with an Enterprise tier at SGD 18,000 over 12–18 weeks.
A store that looks good is not the same as one that sells: the difference is decided in the architecture, before design begins.