Headless commerce separates the storefront customers use from the system that manages commerce. For a Saudi business comparing platforms, the useful question is whether that separation solves a specific limitation in buying, merchandising or operations. A custom storefront adds another application to maintain; it does not automatically improve sales, search rankings or page speed.

This guide compares practical approaches, explains the boundary between the store and ERP, and provides a checklist for evaluating an implementation proposal.

When is headless commerce worth considering?

Start by writing down a constraint your current storefront cannot reasonably solve. Examples include a shared product catalogue across several brands, a purchasing journey with unusual configuration rules, or a customer portal that combines commerce with another business workflow. These are possible project requirements, not evidence that every company needs headless architecture.

If the requirement is a new visual design, clearer navigation or better product descriptions, first evaluate the platform's existing theme and extension options. Record the cost and limitations of that approach before commissioning a separate frontend. Shopify's own guidance recommends assessing whether existing themes, apps and sales channels meet the requirement, and notes the additional development and maintenance involved in headless projects. Source: Shopify headless overview.

Define an acceptance measure for each requirement: a completed order, a correct price, a successful Arabic checkout, or an inventory update within an agreed interval. “Modern technology” is not an acceptance criterion.

Platform approaches to compare in Saudi Arabia

Shopify with a custom storefront

Shopify documents a Storefront API for product discovery and carts, alongside a Customer Account API for customer accounts. A proposal should identify which interface supports each customer journey and how the storefront hands the buyer into checkout. Source: Shopify headless overview.

Ask for a demonstration using the merchant's intended configuration. Include discounts, customer login, shipping choices, failed payments and order confirmation. Do not assume that a feature working in the standard storefront behaves identically in a custom implementation.

Salla with an API-based storefront

Salla's Checkout APIs documentation describes cart operations including creating carts, changing items and applying coupons. It explicitly distinguishes those operations from payment submission and full checkout-step orchestration. This distinction matters when estimating a custom purchase journey. Source: Salla Checkout APIs overview.

Before approving the design, require the supplier to demonstrate the transition from the custom cart to a completed payment and back to a verified order. Document the supported integration route, account prerequisites and any constraints against current provider documentation.

A tailored commerce application

A separate commerce application may be appropriate when the purchasing rules cannot be handled by the selected platform. Treat this as a broader software responsibility: catalogue management, pricing, order states, administration, security updates and operational support all need owners.

Compare the full operating scope with extending an existing platform. Our custom software decision guide explains how to separate a business requirement from a preference for a particular implementation.

Connecting the store to ERP or Odoo

An attractive storefront can still create expensive manual work if orders and stock are inconsistent. Agree which system owns each record before building the integration. The following is a suggested design checklist, not a description of every ERP product:

  • Product identity: maintain a stable mapping between storefront products, variants and ERP item codes.
  • Prices: identify the owner of base prices, customer-specific prices and promotion rules.
  • Inventory: distinguish available stock, reservations and completed deductions; agree how delayed updates are handled.
  • Orders: send a stable external order identifier and prevent duplicate processing when a request is retried.
  • Payments: distinguish pending, confirmed, failed and refunded states; do not treat a browser return page as payment proof.
  • Returns: define how partial refunds, returned quantities and stock adjustments are reconciled.

For example, imagine a retailer selling the last unit online while a branch sells the same item. This hypothetical scenario exposes decisions about reservation timing and conflict handling. A successful integration test must show the agreed response, not simply show that an API returned success.

For an ERP integration project, request a field map, retry policy, reconciliation screen and an assigned owner for failed messages. Confirm the actual API access and integration permissions available in the selected ERP deployment before estimating the work.

Test the Arabic buying journey before launch

Use realistic product names, variant labels and address lengths in both languages. Test right-to-left layouts, mixed Arabic and Latin text, phone country codes, validation messages and the mobile keyboard. Keep currency and price formatting consistent between product, cart and checkout screens.

Run end-to-end tests for guest and returning customers, coupons, unavailable stock, shipping changes, payment rejection, payment completion and refunds. Test the providers and methods the merchant intends to offer in their supported test environment. API availability alone does not establish support for every payment or delivery option.

Check that refreshing a page or retrying after a network interruption cannot create a second order. Agree what the customer sees when a service is unavailable and how support staff find the relevant transaction.

Preserve search visibility during migration

Before changing platforms, export the existing public URLs and identify pages that receive search traffic or links. Create a destination for each retained product, category and useful article. Use a permanent redirect when a URL genuinely moves, and avoid sending every retired product to the home page.

Review canonical URLs, Arabic and English language alternates, internal links, sitemap entries and product information available to search crawlers. Test representative pages in rendered HTML as well as the browser. Compare titles and descriptions before and after migration so that useful information is not lost with the old theme.

Measure product views, cart additions, checkout starts and confirmed purchases consistently. Define consent behavior and deduplication rules before launch. A platform migration is not proof of an SEO improvement; assess results against the previous baseline and account for changes in demand and campaigns.

What should a proposal include?

Ask suppliers to price the following separately: discovery, design, storefront development, platform configuration, ERP integration, migration, testing, hosting and ongoing support. List third-party subscriptions and responsibilities without assuming they are included in the development fee.

The proposal should name the checkout route, the owner of each data source, supported languages, acceptance tests, migration plan, monitoring arrangements and rollback conditions. Include source-code access and documentation in the handover requirements. Agree a realistic launch scope before estimating delivery dates.

Questions businesses often ask

Does headless commerce improve SEO automatically? No. Search visibility depends on accessible content, sound implementation and relevance. A custom storefront can also introduce indexing or navigation problems if those requirements are missed.

Do we need to replace our ERP? Not necessarily. First assess the existing system's interfaces, data quality and operational limitations. The storefront and ERP decisions should each follow a documented requirement.

Can we launch in stages? Plan a limited proof of concept around one complete purchase journey and its ERP updates. Expand only after the acceptance checks pass and the team understands support responsibilities.

Discuss your store and integration requirements

Review Tarawud's e-commerce services, explore custom software development, or contact the team with your current platform, ERP, sales channels and main operational problem. Those details help define a useful first assessment and an appropriate implementation scope.