Retail App Development

Companies building direct-to-consumer retail platforms, marketplace apps, loyalty programmes, and omnichannel commerce tools need engineering teams who understand the specific data architecture challenges of product catalogues at scale, real-time inventory sync across fulfilment nodes, and the transactional consistency that checkout and payment processing require. Scrums.com provides dedicated software engineering teams for retail app development, deploying production-ready systems with append-only order ledgers, configurable promotions engines, POS integration adapters, and the personalisation infrastructure that drives customer retention.

Product Catalogue, Inventory Sync, and Order Management Architecture

The foundation of a retail platform is the product catalogue and its relationship to inventory across multiple fulfilment locations. Products have complex attribute structures (size, colour, material, variant combinations) that drive both the browse experience and fulfilment logic.

The product model separates product master records from product_variants. Each product carries base attributes (brand, category, description, media); each variant carries a unique SKU, its own price overriding the product base price, weight, and dimensions. Pricing is versioned through a product_price_history table: the current price is the row with no superseded_at value, and price changes are recorded as new rows rather than updates to existing ones.

Inventory is managed at the location level through a warehouse_inventory table: variant_id, location_id, quantity_on_hand, quantity_reserved, and quantity_available (a generated column: on_hand minus reserved). quantity_on_hand is never incremented or decremented directly; every stock movement writes to an inventory_transactions ledger table with a transaction type (PURCHASE_RECEIPT | SALE | RETURN | ADJUSTMENT | TRANSFER), the movement quantity, and a reference to the source document. quantity_on_hand is a materialised aggregate of the ledger: the ledger is the source of truth.

Reservation management uses SELECT...FOR UPDATE to lock the inventory row at checkout, compares quantity_available against the requested quantity, and writes a reservation row only if sufficient stock exists. Reservations expire after a configurable window if payment is not completed. Order fulfilment assignment considers proximity to the customer, available inventory at each location, and a fulfilment_routing_config table that encodes business rules: for example, never fulfil from a location marked STORE_PICKUP_ONLY unless the order type is click-and-collect.

Omnichannel Cart, Checkout, and Payment Processing

The cart model must support both anonymous sessions and authenticated accounts, persist across devices, and handle concurrent modification when a customer adds items from multiple sessions simultaneously.

Carts are stored as cart_sessions with a session_token for anonymous users and a customer_id for authenticated ones. When an anonymous user authenticates, sessions are merged by transferring line items and discarding the anonymous session: the merge is idempotent on (customer_id, variant_id). Cart line items reference variants, not products, so size and colour selections are captured at add-to-cart time. The cart total is always computed from current line items and active pricing, never stored as a mutable field.

Checkout moves through a defined state machine: CART / CHECKOUT_INITIATED / ADDRESS_CONFIRMED / SHIPPING_SELECTED / PAYMENT_PROCESSING / PAYMENT_CONFIRMED / ORDER_PLACED | PAYMENT_FAILED. Each transition is appended to a checkout_events table. Payment attempts write payment_events rows: attempt_id, payment_provider, amount, currency, status (PENDING | AUTHORISED | CAPTURED | FAILED | REFUNDED), and provider_response (JSONB). The payments ledger is append-only: payment status is derived from the latest payment_events row for each attempt, never from a mutable status field.

Order state after placement follows a separate machine: PLACED / CONFIRMED / PICKING / PACKED / DISPATCHED / IN_TRANSIT / DELIVERED | FAILED | CANCELLED | RETURNED. Status transitions write to order_status_events. Returns initiate a return_requests sub-workflow with its own state machine (REQUESTED / APPROVED | REJECTED / ITEM_RECEIVED / REFUND_INITIATED / REFUND_COMPLETED), and refunds are recorded in the payment_events ledger against the original payment attempt reference.

Retail apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

Customer Loyalty, Personalisation, and Promotions Engine

Loyalty programmes track customer-earned points as a ledger, not a mutable balance. A loyalty_ledger table records every point earn and redemption as an append-only row: customer_id, transaction_type (EARN | REDEEM | EXPIRE | ADJUST), points, reference_order_id, and effective_at. The customer's available balance is always computed as the SUM of the ledger: never stored as a field that can be overwritten. Point expiry is handled by writing negative EXPIRE rows on the expiry schedule, not by modifying historical earn rows. This makes the audit trail complete: any balance discrepancy can be traced to a specific ledger entry.

Personalisation relies on a customer_behaviour_events table that captures product views, searches, adds-to-cart, purchases, and returns with the associated variant_id, category, brand, and timestamp. A recommendation engine reads this event history to score affinity by category and brand, producing a customer_affinity_scores materialised view refreshed on a configurable cadence. Recommendation placements (home page, product detail pages, cart upsell) are driven by a recommendation_config table that controls which scoring model applies to each placement, allowing merchandising teams to swap strategies without engineering involvement.

The promotions engine evaluates discount rules at checkout. Promotion records specify type (PERCENTAGE_OFF | FIXED_AMOUNT_OFF | BUY_X_GET_Y | FREE_SHIPPING | BUNDLE_DISCOUNT), eligibility criteria (minimum order value, specific categories, specific SKUs, customer tier, first-order only), and constraints (max_uses total, max_uses_per_customer, valid_from, valid_until). Eligibility evaluation reads these from config tables rather than hard-coded business logic. A promotion_applications append-only table records every discount applied at checkout: order_id, promotion_id, applied_discount_amount, and the eligibility snapshot at time of application. SELECT...FOR UPDATE on the promotions row prevents max_uses from being exceeded under concurrent checkout.

Customer segmentation uses a customer_segments config table with segment definitions expressed as rule sets: purchase frequency thresholds, lifetime value bands, category affinity scores, inactivity windows. Segment membership is computed by a scheduled job that writes to customer_segment_memberships, and membership history is retained so that campaign performance can be attributed to the segment state at send time, not the current state.

POS Integration, In-Store Operations, and Retail Analytics

Point-of-sale integration connects the app's inventory and order data to in-store systems without creating tight coupling that breaks when POS vendors upgrade their APIs. A pos_adapter layer normalises transactions from Lightspeed, Square, Shopify POS, and custom systems into a standard pos_transactions schema: location_id, transaction_id (provider-native), transaction_type (SALE | REFUND | EXCHANGE | VOID), line items, payment method, operator_id, and transaction_at. Deduplication uses a UNIQUE constraint on (pos_provider, provider_transaction_id) with ON CONFLICT DO NOTHING. Switching POS vendors requires a new adapter, not changes to the inventory or order logic that consumes pos_transactions.

In-store inventory operations (stocktakes, adjustments, inter-store transfers) write to the same inventory_transactions ledger used by the e-commerce flow, so online and in-store inventory shares a single source of truth. Stocktake workflows use a stocktake_sessions table: location_id, initiated_by, status (OPEN | IN_PROGRESS | RECONCILING | COMPLETE), and a stocktake_counts child table capturing counted quantities per variant. When reconciliation completes, adjustment inventory_transactions are written for any variance: the stocktake record and count rows are immutable after COMPLETE.

Click-and-collect workflows link an online order to a specific store location. The store's inventory is reserved at order placement using the same SELECT...FOR UPDATE reservation pattern as the e-commerce checkout. A collection_readiness_events table tracks PICKED, PACKED, and READY_FOR_COLLECTION states with timestamps, and customer notifications fire on READY_FOR_COLLECTION via the notification adapter layer.

Retail analytics materialised views provide operations dashboards without querying transactional tables directly. Standard views include revenue_by_product_by_day, inventory_turnover_by_sku_by_period, return_rate_by_category, and basket_composition_by_customer_segment. Because these views aggregate from append-only ledger tables, they can be refreshed at any time to reflect corrections without manual data patching.

Frequently Asked Questions

How does the inventory model prevent overselling under concurrent checkout?

When a customer initiates checkout, the platform uses SELECT...FOR UPDATE to lock the relevant inventory row for the chosen fulfilment location. The reservation is only written if quantity_available (the computed column of quantity_on_hand minus existing reservations) covers the requested quantity. Concurrent requests for the same variant queue behind the lock; each sees the current available quantity before writing its reservation. Reservations expire after a configurable window if payment is not completed, releasing stock for other orders.

Can promotions rules be updated by merchandising teams without a code deployment?

Yes. Promotion rules (type, eligibility criteria, discount values, max usage limits, and validity windows) are stored in configuration tables rather than application code. Merchandising teams can create, update, and deactivate promotions through an admin interface. The eligibility evaluation engine reads current rule state from the database at checkout time, so changes take effect immediately without a deployment.

How does the platform handle omnichannel inventory across online and in-store channels?

Online and in-store inventory share a single inventory_transactions ledger keyed by location_id and variant_id. POS transactions, e-commerce orders, stocktake adjustments, and inter-store transfers all write to the same ledger. quantity_on_hand is always a materialised aggregate of inventory_transactions, so any channel that modifies stock is immediately visible to all others. Click-and-collect reservations lock in-store stock using the same SELECT...FOR UPDATE pattern as web checkout, preventing double-allocation.

How is the customer loyalty balance protected against data corruption?

The loyalty balance is never stored as a mutable counter. Every point earn and redemption writes an append-only row to the loyalty_ledger table. The customer's current balance is always computed as the SUM of all ledger rows for that customer. If a transaction fails partway through, no ledger row is written and the balance is unaffected. Any discrepancy can be traced to a specific ledger entry by time, transaction type, and order reference.

How long does it take to deploy a retail platform with Scrums.com?

Scrums.com deploys dedicated engineering teams within 21 days. The team works within your existing infrastructure, integrates with your POS and payment providers via the adapter layer, and delivers core catalogue, inventory, and checkout functionality in the first sprint. Scope and timeline are agreed before engagement begins.