Building an ecommerce app is largely about consistency between what the customer sees and what is actually available. Catalogue data changes, stock moves, prices update, and the app is frequently working from cached information on an unreliable connection. This guide covers the architectural relationship with your commerce backend, catalogue and search design, cart and inventory consistency, checkout construction, and how the app should behave when the network is not cooperating.
Architecture and Backend Relationship
The first decision is whether the app talks to an existing commerce platform or to services you build. Most projects should use an existing platform headlessly, because catalogue management, tax, promotions, and order handling are solved problems with substantial hidden complexity. Building them yourself is rarely differentiating and always expensive to maintain.
Headless Commerce Platform
The app consumes APIs from an established platform holding catalogue, orders, and inventory. Fastest route to a working product and the correct default for most builds.
Custom Commerce Backend
Justified where your model differs fundamentally from what platforms support, such as unusual pricing logic or complex B2B ordering. Our ecommerce development work assesses which applies.
The API Layer in Between
A thin service shaping platform responses for mobile rather than calling the platform directly from the app. This isolates you from platform changes and reduces payloads.
Integration With Business Systems
Orders, stock, and customers usually need to reach an ERP or accounting system. Our ERP integration work covers this synchronisation and its failure handling.
Catalogue and Search Design
Catalogue architecture determines how fast browsing feels, and search determines whether people find anything. Both are read-heavy with occasional bulk updates, which is a caching problem more than a database problem. Variant modelling is the specific complexity that catches teams out, because products with multiple options combine faster than expected.
Modelling Products and Variants
Size, colour, and configuration combinations multiply quickly. Model variants as first-class entities with their own stock and pricing rather than as attributes on a product.
Caching Catalogue Data
Catalogue reads dominate traffic. Cache aggressively with invalidation triggered by platform updates rather than short expiry windows that produce unnecessary load.
Search and Filtering Architecture
A dedicated search index rather than database queries with wildcards. Faceted filtering across category, price, and attributes needs index support to stay fast.
Handling Catalogue Updates
Bulk imports and price changes need to propagate without serving stale data or causing a cache stampede. Plan this rather than discovering it during a sale.
Image Delivery at Scale
Product imagery dominates payload weight. Serve display-sized variants over a content delivery network rather than full-resolution originals.
Cart, Inventory and Consistency
This is where ecommerce apps genuinely differ from other applications. The cart is a promise the system may not be able to keep, since stock can disappear between adding and paying. How you handle that gap determines whether customers hit failures at checkout, which is the most expensive place to fail.
Deciding Where the Cart Lives
Server-side carts survive device changes and allow abandoned cart recovery. Client-only carts are simpler and lose state. Most products need server-side.
Stock Validation Timing
Validate at add-to-cart, at checkout entry, and at payment. Checking only once means overselling, and checking too aggressively creates unnecessary load.
Reservation Versus Optimistic Handling
Reserving stock at cart addition prevents disappointment and can strand inventory. Optimistic handling with checkout validation is usually the better trade for consumer retail.
Price Consistency
Prices can change while an item sits in a cart. Decide explicitly whether the cart honours the original price and communicate it, since silent changes generate disputes.
Concurrent Update Handling
Two customers buying the last item simultaneously must produce one success and one clear failure. Our API development work handles this with proper transaction boundaries.
Checkout and Payment Architecture
Checkout is where abandonment concentrates and where security scope is decided. The architectural principle is keeping card data entirely out of your systems by using a tokenising provider, which reduces compliance burden dramatically. The rest is minimising steps and handling failure states clearly.
Tokenised Payment Handling
Card data goes directly to the payment provider and never touches your servers. Our payment gateway integration work keeps PCI scope minimal by design.
Native Payment Methods
Platform wallets remove most checkout friction on mobile and should be the primary path rather than an alternative offered below a card form.
Guest Checkout Support
Requiring account creation before purchase costs conversions. Support guest purchase with optional account creation afterwards.
Order State Machine
Orders move through defined states with recorded transitions. Ambiguous order state is the root of most customer service escalation in commerce.
Idempotent Order Submission
Network retries must not create duplicate orders. Idempotency keys on order creation are essential rather than a refinement.
Offline Behaviour, Sequencing and Pitfalls
Mobile commerce happens on unreliable connections, and an app that fails on a weak signal loses the sale rather than delaying it. Combine that with a sensible build order and the pitfalls below and you avoid most of the rework that hits ecommerce app projects late.
Suggested Build Order
Catalogue and browsing, then search, then cart, then authentication, then checkout, then order history, then account and returns handling.
Offline Browsing and Cached Catalogue
Recently viewed products and cart contents should survive connection loss. Browsing cached content beats an error screen.
Pitfall: Modelling Variants as Attributes
Treating size and colour as product fields rather than distinct purchasable entities breaks stock tracking and requires restructuring later.
Pitfall: Validating Stock Only Once
Single-point validation produces oversold orders and refund handling. Validate at multiple points along the purchase path.
Pitfall: Non-Idempotent Order Creation
Retries on a flaky connection creating duplicate orders is a common and entirely preventable failure that damages trust immediately.
FAQs
Should an ecommerce app use a commerce platform or custom backend?
Use an established platform headlessly in most cases. Catalogue management, tax, promotions, and order handling carry substantial hidden complexity and are rarely differentiating. Build custom only where your commercial model genuinely differs from what platforms support.
Where should the shopping cart be stored?
Server-side for most products, since it survives device changes, enables abandoned cart recovery, and keeps pricing and stock validation authoritative. Client-only carts are simpler but lose state and cannot support recovery flows.
How should stock be validated during checkout?
At multiple points: when items are added, when checkout begins, and immediately before payment. Validating only once produces oversold orders. Optimistic handling with checkout validation usually beats reserving stock at cart addition for consumer retail.
How do I keep card data out of PCI scope?
Use a tokenising payment provider so card details go directly from the client to the provider and never touch your servers. This reduces compliance burden substantially compared with handling card data in your own systems.
How should product variants be modelled?
As first-class purchasable entities with their own stock levels and pricing, not as attributes on a parent product. Treating size and colour as fields breaks stock tracking and requires restructuring once combinations multiply.
What should an ecommerce app do offline?
Serve cached catalogue and recently viewed products, preserve cart contents locally, and queue actions for retry. An error screen on a weak connection loses the sale entirely, whereas degraded browsing keeps the customer engaged.
