Commerce software for rules a standard storefront cannot carry

Build when a revenue-critical catalogue, price, customer, order, inventory, fulfilment, or integration rule cannot be represented through sensible configuration and the value covers ongoing ownership. Buy when the model is common. A custom storefront or integration over an established commerce backend may be the lower-risk middle path.

Yes, if its APIs, webhooks, limits, extension points, and operational model support the required behaviour. We test the risky transactions early and document which system owns product, price, stock, customer, order, payment, return, and fulfilment state. Headless delivery does not remove backend limits.

We define inventory authority, reservation timing, order states, idempotency, retries, event ordering, reconciliation, and staff recovery for each channel. External systems may update asynchronously, so the platform shows stale or conflicting state rather than promising universal real-time consistency.

We prefer hosted or tokenised payment components to reduce card-data exposure and map approved security, privacy, accessibility, tax, consumer, and record requirements into scope. The retailer and its advisers own legal interpretation, policy, notices, and risk acceptance. Software delivery does not certify compliance.

A focused release starts at $40,000 and usually takes twelve to eighteen weeks. Large catalogues, B2B pricing, several markets, native apps, marketplace roles, complex tax, difficult migration, or many inventory and fulfilment systems add scope. The proposal names assumptions, exclusions, third-party fees, and support.

Yes, for a bounded task with approved product attributes, questions, outputs, exclusions, and evaluation examples. A recommendation is not a diagnosis or a guaranteed match. Beauty, legal, product, and content owners approve claims and low-confidence behaviour, while product availability and market eligibility are checked before purchase.

A shade matcher recommends a shade; virtual try-on renders an already-chosen shade. Test on a small hard-to-judge catalogue segment: calibrate digital against real shades, then measure conversion, order value, repeat, and returns before wider rollout. A recommendation must respect inventory truth.

Yes, after identity, subscription state, eligible charge, points timing, cancellation, skip, refund, discount order, and balance reversal are defined. The commerce, subscription, payment, and loyalty systems each need a clear source-of-truth role and reconciliation. One app firing an event does not guarantee the others processed it.

Ask for reviews while the experience is fresh, feature customer photos on product pages, and reward photo reviews with loyalty points. Tie reviews into the programme: points for photo reviews and referrals, early access to launches, tiered rewards.

Track second-purchase rate within the replenishment window for your products. Measure what the post-purchase sequence changes: day-one education, usage tips, review requests, replenishment reminders, and referrals. Set the auto-replenishment incentive by testing what moves repeat purchase at your price point, not by industry averages.

Treat each sellable variant as a durable identifier linked to its style, size system, colour, market, channel, price, media, and inventory source. The interface can group variants for shoppers, but availability, order, fulfilment, return, and reporting must preserve the exact item and source state.

Yes, for a bounded product range with approved attributes, return reasons, customer inputs, outputs, and evaluation examples. A recommendation should show uncertainty and cannot guarantee fit. Historical purchases and returns can be biased or incomplete, so quality is measured by segment and compared with simpler guidance.

Nested apparel variants need per-SKU inventory tracking, per-variant image assignment, product-level size guides, and canonicalised variant URLs from day one: uncanonicalised variant URLs are a quiet SEO killer on fashion stores. The dress is available but the requested size is not; that is the inventory-modelling failure.

Buyers cannot see real fit, so sizing drives most apparel returns. Size guides need cm-level data, model fit reference (height, weight, size worn), fit and stretch notes, cross-brand matching, and a feedback loop from return reasons. Virtual try-on is buying confidence, not a wow factor: trustworthy input, believable result, understood recommendation, pre-checkout verification.

Ask about your situation, not platform reputation. Shopify: DTC speed-to-market and social commerce. Magento: complex catalogues, multi-brand, B2B wholesale, ERP depth. WooCommerce: indie code ownership.