The Reality
What Breaks First
in Retail Tech
Most retail and commerce platforms don't fail in a single moment. They accumulate fragility. Inventory drifts. Order statuses go stale. Integrations become brittle. By the time it's visible as a business problem, the architectural debt has been building for years.
Inventory mismatch across channels
What's in the warehouse doesn't match what's on Flipkart, Amazon, or your own site. Oversells happen. Cancellations spike. Ops teams spend half their week reconciling what should be automated.
Order lifecycle fragmentation
Orders pass through five systems - OMS, ERP, warehouse, courier, returns - each with its own version of the truth. A customer asks where their order is. No one has a clean answer.
Brittle marketplace integrations
Amazon, Flipkart, Meesho connectivity built quickly and never properly maintained. Each marketplace update requires a manual fix. There's no abstraction layer - just bespoke code per channel.
ERP and POS sync that's always slightly wrong
SAP or another ERP is the system of record, but the data is always a few hours behind. POS transactions take too long to reflect. Finance closes the books against numbers that don't reconcile.
Payment and checkout complexity
Multiple payment gateways, regional configurations, refund workflows, and reconciliation that doesn't tie back to orders cleanly. Every payment provider behaves differently under failure.
No visibility into fulfilment
You don't know what percentage of orders are on time, what's stuck at which courier, or where the bottleneck is in the warehouse pick-pack-ship cycle - until a customer complaint makes it visible.
Reconciliation issues that compound
Revenue in the payment gateway doesn't match orders in the OMS, doesn't match invoices in the ERP. Someone manually bridges the gap every week. As volume grows, so does the discrepancy.
Sale-period scaling failures
The platform handles normal traffic fine. A flash sale or campaign at 10x normal volume causes API timeouts, checkout failures, and inventory inconsistencies that take days to untangle.
Courier performance you can't see until it's a complaint
SLA breaches, NDR spikes, and RTO (Return to Origin) rates climbing without anyone noticing until the customer NPS drops. Courier data lives in five different portals and nobody aggregates it until something goes wrong.
POS data that never reaches the commerce platform
In-store transactions processed on Pine Labs or Mswipe terminals that don't sync reliably to the ERP or OMS. Omni-channel reports are always slightly wrong because offline sales are still partially manual.
Returns workflows handled outside the system
Return requests raised on Flipkart or Meesho trigger manual ops work. Refunds processed in the gateway, not reflected in the OMS. Returned stock re-enters the warehouse but the inventory system doesn't know until someone physically counts it.
Advisory Areas
What I Help Retail
Businesses Solve
Omni-Channel Commerce Architecture
Designing the data flows, system boundaries, and integration patterns that let retail platforms operate consistently across physical stores, digital channels, and marketplace ecosystems.
Marketplace Integration Strategy
Building maintainable, resilient connectivity to Amazon, Flipkart, Meesho, Nykaa, and other marketplace ecosystems - with a proper abstraction layer, not one-off connectors per channel.
Order Management & Orchestration
OMS design, order lifecycle state management, fulfilment routing, and the integration contracts that keep orders moving cleanly from placement through delivery and returns.
Real-Time Inventory Synchronization
Architecture for keeping inventory accurate across warehouses, channels, and third-party logistics partners - without oversells, ghost inventory, or reconciliation backlogs compounding daily.
ERP / SAP / POS / Payment / Logistics Integration
Defining how your commerce platform connects to back-office systems. Integration patterns that are stable, auditable, and survivable when individual downstream systems have downtime.
Platform Modernization & Microservices
Staged decomposition of monolithic retail or commerce platforms into independently deployable services - without disrupting ongoing operations or the delivery schedules sale seasons impose.
Analytics & Operational Visibility
Building the data layers, event pipelines, and operational dashboards that give commerce teams real-time visibility into what's actually happening across orders, inventory, and fulfilment.
Engineering Leadership & Delivery Governance
Working with founders, CTOs, and engineering leads to build the standards, team structures, and delivery processes that allow commerce engineering to move fast without breaking operations.
Distribution Management & DMS Architecture
Advisory on DMS platforms covering FMCG and pharma distribution - order booking via salesperson apps, beat planning, scheme management, distributor-to-retailer fulfilment workflows, and secondary sales data flowing back into demand planning.
Supply Chain Platform Architecture
Designing the platform architecture for supply chain layers - demand planning integration, procurement workflows, vendor onboarding, and the data contracts between OMS, WMS, and SCM that keep inventory positioning grounded in real sell-through data.
3PL & Warehouse Management Integration
Integrating third-party logistics providers and WMS platforms into your commerce stack - covering inbound receipts, bin-level inventory, pick-pack-ship flows, and the bidirectional sync that keeps your OMS and warehouse in agreement without manual reconciliation.
Order Management Architecture
Inside an OMS That Handles
Scale Without Breaking
Order management is the operational backbone of any commerce platform. When it's done well, orders flow invisibly from placement to delivery. When it's done poorly, every new channel, new courier, or new sale season creates a new category of manual intervention.
The root cause is almost always the same: orders are a data record when they need to be a state machine. Here's what a properly architected OMS looks like at each stage.
01
Order Ingestion & Normalisation
Orders arrive from your own site, Amazon, Flipkart, Meesho, Myntra, and physical POS - each with a different schema and fulfilment SLA. Normalisation at ingestion converts every channel's order format into a single internal order model before any downstream process touches it. Downstream systems never parse channel-specific formats.
02
Inventory Reservation & Allocation
The moment an order is accepted, inventory must be reserved against the right warehouse or fulfilment location. Soft reservation during checkout, hard allocation at confirmation. Multi-warehouse allocation logic, safety stock buffers, and priority rules for same-day vs standard delivery all live here - not scattered across the ERP and warehouse system.
03
Courier Selection & Dispatch
Courier selection logic - based on pincode serviceability, delivery SLA, weight/volume, cost, and real-time courier performance - should run automatically. Shiprocket, Delhivery, Bluedart, Ecom Express, XpressBees, and Shadowfax all have different pincode coverage and failure rates. The OMS picks the right one; ops teams shouldn't be making that call per order.
04
Tracking & Status Updates
Tracking events from couriers need to flow back into your system in near-real-time, update order status, and trigger customer communications - not sit in a portal nobody checks until a complaint arrives. When a courier marks a delivery as failed (NDR), the OMS should immediately trigger the retry or RTO workflow, not wait for an ops agent to notice it the next morning.
05
Returns & RMA Orchestration
A return request on Flipkart or Meesho triggers a chain: reverse pickup scheduled, item quality check at warehouse, inventory re-entry or disposal decision, refund initiation, and finance reconciliation. Each of those steps needs to be automated and auditable. When returns are handled ad hoc, the gap between what customers expect and what ops delivers grows with every sale season.
06
Reconciliation & Finance Sync
Every marketplace pays out on a cycle, deducting returns, commissions, and penalties. Every courier charges on actuals that differ from estimates. Reconciling what you should have received against what actually landed in your account - per channel, per courier, per SKU - is a weekly finance task that should be automated, not the reason two people spend three days closing the month.
Domain Knowledge
Retail Workflows & Platforms
I Understand
Commerce complexity doesn't live in any one system. It lives in the gaps - between the OMS and the ERP, between the inventory system and the marketplace feed, between what the payment gateway recorded and what finance can close against.
Commerce & Channels
B2B Commerce PlatformsB2C EcommerceD2C Brand PlatformsOmni-Channel RetailQuick CommerceSubscription CommerceMarketplace Seller PlatformsHeadless Commerce
Marketplaces (India & International)
Amazon Seller CentralAmazon Vendor CentralAmazon SP-API / MWSFlipkart Seller HubFlipkart Quick CommerceMeesho Supplier APIMyntra PartnerNykaa SellerTata CLiQJioMartReliance DigitalSnapdealIndiaMart (B2B)Udaan (B2B)PepperfryBigBasket
POS Systems
Pine Labs (POS Terminal)MswipeRazorpay POS / SmartPOSPaytm POSEzetap (Razorpay)Shopify POSSquare POSLightspeedGinesys (Retail ERP + POS)Posist (F&B POS)Oracle MICROSMPOS / Mobile POS
Courier & Logistics Aggregators
ShiprocketDelhiveryBluedart (DHL)DTDCEcom ExpressXpressBeesShadowfaxFedEx IndiaEkart (Flipkart Logistics)Amazon LogisticsDunzoPorterRivigoPickrr
ERP & Back-Office Systems
SAP S/4HANASAP Business OneOracle NetSuiteMicrosoft Dynamics 365Tally ERPZoho ERPMarg ERPBusy AccountingWMS / 3PL APIsReturns & RMA Workflows
Distribution & DMS Platforms
BizomFieldAssistMeraqiYara DMSSAP DMSCustom DMSBeat PlanningSecondary SalesScheme ManagementDistributor PortalsFMCG DistributionPharma Distribution
WMS, 3PL & Supply Chain
Increff WMSVinculum WMSFynd WMSSnapFulfilOracle WMSManhattan AssociatesDelhivery FulfilmentBlue Yonder SCMSAP SCMCold Chain LogisticsFEFO Picking3PL ASN / GRN
Ecommerce Platforms & Aggregators
Shopify / Shopify PlusMagento / Adobe CommerceWooCommerceBigCommerceSalesforce Commerce CloudUnicommerceIncreff OMSVinculum
Operations & Analytics
Inventory ReconciliationOrder Lifecycle TrackingFulfilment AnalyticsRevenue ReconciliationCourier Performance MonitoringNDR & RTO AnalyticsOperational Dashboards
Marketplace Architecture
Marketplace Integrations That
Don't Break Your Operations
The problem with most marketplace integrations isn't the initial build - it's that they're built once, never abstracted, and become maintenance nightmares by the third or fourth channel. Each marketplace has its own schema, its own listing API, its own inventory feed, its own order webhook, and its own payment settlement format. Without a shared abstraction layer, every new marketplace is a full rebuild.
Amazon India & International
Seller CentralVendor CentralSP-APIFBAAdvertising API
Amazon integration covers product listing sync, inventory feeds, order acknowledgement, shipping confirmation, FBA vs FBM fulfilment logic, returns reconciliation, and advertising data pulls. SP-API (Selling Partner API) replaced MWS and has distinct auth patterns and rate limits. FBA inventory updates and restock triggers are a separate integration layer from order management.
Flipkart & Ekart Logistics
Flipkart Seller HubFlipkart APIEkartFK Quick
Flipkart's seller API covers catalog, pricing, inventory, orders, returns, and settlement. Ekart as a fulfilment channel has its own label generation and tracking integration. Flipkart Quick (hyperlocal) uses a separate inventory model with slot-based availability. Return quality checks and seller protection claims have their own workflow - not part of the standard order API.
Meesho, Glowroad & Social Commerce
Meesho SupplierMeesho APIGlowroadDealShare
Meesho's API covers catalog, inventory push, order pull, and return workflows. Settlement frequency and return rate patterns differ significantly from Amazon/Flipkart - important for cash flow and inventory planning. Social commerce platforms like Glowroad and DealShare have more manual touchpoints and less mature API coverage; integration patterns need to account for fallback and manual sync scenarios.
Myntra, Nykaa & Fashion Platforms
Myntra PartnerNykaa SellerAjioTata CLiQ
Fashion marketplaces have specific catalog requirements - size charts, fabric details, occasion tags - and strict image standards that require normalisation pipelines before listing. Myntra's content-heavy model means catalog sync is as complex as inventory sync. Returns rates in fashion are significantly higher than in other categories, requiring dedicated RMA workflow design.
B2B Marketplaces
IndiaMartUdaanJioMart B2BTradeindia
B2B marketplace integration involves catalog management for bulk SKUs, tiered pricing per buyer segment, credit terms enforcement, and fulfilment at pallet or carton level rather than individual unit. IndiaMart lead integration - pulling buyer enquiries into your CRM or ERP - is often a higher-ROI integration than full order sync for smaller B2B operations.
Quick Commerce & Hyperlocal
BlinkitSwiggy InstamartZeptoBigBasketDunzo
Quick commerce platforms operate on dark store inventory, not central warehouse stock. Integration means real-time inventory sync per dark store location, not per warehouse. Availability windows are typically 10–30 minutes, which requires an entirely different cache invalidation and availability update strategy compared to standard marketplace feeds that tolerate 15–60 minute update cycles.
POS Architecture
POS Integration Is More
Complex Than It Looks
A POS terminal isn't just a payment device - it's a transaction record, an inventory event, a customer data point, and a reconciliation entry, all at the moment of sale. When POS isn't properly integrated into the commerce stack, offline transactions become an island. Inventory drifts. Finance reconciles against partial data. Omni-channel becomes aspirational rather than operational.
Hardware POS Terminals (India)
Pine LabsMswipeEzetapRazorpay SmartPOSPaytm POS
India-market POS terminals from Pine Labs, Mswipe, and Ezetap (now Razorpay) handle card, UPI, and wallet payments. Their APIs expose transaction events and reconciliation reports. The integration challenge is getting those events into your OMS and ERP in real-time, not in batch at end of day - so omni-channel stock visibility is live, not stale by 24 hours.
Software POS Systems
Shopify POSSquareLightspeedGinesysPosist
Software POS systems like Shopify POS and Lightspeed have richer API surface areas - they expose inventory, customer, and discount data alongside transactions. Ginesys is widely used in Indian retail for its ERP+POS combination; Posist dominates F&B. Integration here is about syncing sales orders, inventory deductions, and loyalty events into a central system rather than just capturing payment records.
Offline-First & Sync Architecture
Offline ModeSync QueueConflict Resolution
Store connectivity isn't guaranteed. A POS integration that fails when the internet drops is a business risk during high-footfall periods. Offline-first architecture means transactions queued locally, synced when connectivity returns, with conflict resolution logic for inventory that may have sold through the online channel in the interim. This is where most POS integrations underinvest.
Omni-Channel Inventory from POS
Real-Time DeductionBOPISShip-from-Store
Each POS sale should trigger an inventory deduction visible to the online channel within seconds, not hours. Buy Online Pick-up In-Store (BOPIS) and ship-from-store fulfilment both depend on accurate store-level inventory. When POS and ecommerce inventory are out of sync, you're either overselling online or leaving store stock unavailable to the broader customer base.
ERP Integration Architecture
ERP & Back-Office Integrations
That Actually Stay Stable
ERP integration is where commerce platforms most commonly accumulate technical debt. End-of-day batch jobs that replace real-time sync. Direct DB connections instead of API contracts. Custom fields added to work around schema mismatches. The result is a commerce-ERP integration that works until it doesn't - and when it breaks, nobody knows where to start. Here's how I approach each ERP integration layer.
SAP S/4HANA & SAP Business One
SAP S/4HANASAP Business OneSAP BAPIRFC / IDocSAP Fiori
SAP integration for commerce covers order sync (OMS-to-SAP for financial posting), inventory master data sync (SAP→OMS for stock positions), and accounts receivable/payable for marketplace settlement reconciliation. SAP S/4HANA uses BAPIs and RFC calls for transactional integration and IDocs for batch. OData APIs are the modern path for REST-based integration. The architecture decision that matters most is whether to integrate synchronously (blocking OMS operations on SAP confirmation) or asynchronously (publish to queue, SAP processes independently) - the latter is almost always the right answer for commerce platforms where SAP downtime must not block order processing.
Oracle NetSuite
NetSuite SuiteTalkSuiteScriptREST APICSV ImportSaved Searches
NetSuite is commonly used by mid-market D2C and ecommerce businesses as the ERP of record. NetSuite's SuiteTalk REST API covers sales orders, inventory items, customers, and financial transactions. The integration covers order creation from OMS, inventory sync back to OMS, and payment/settlement data flowing to NetSuite for revenue recognition. The practical challenge is NetSuite's API rate limits and the complexity of its multi-subsidiary data model for businesses operating across multiple entities or geographies.
Microsoft Dynamics 365
Dynamics 365 FinanceDynamics SCMDataverse APIPower Automate
Dynamics 365 Finance and Supply Chain Management is common in mid-to-large retail and manufacturing businesses. The Dataverse API (formerly Common Data Service) provides REST-based access to business entities. Commerce integration covers order sync, inventory positions from Dynamics SCM, procurement workflows, and financial close data for reconciliation. Power Automate is often used for lighter integration flows, but for high-volume commerce data the Dataverse API with proper batch handling is more reliable than Power Automate triggers at scale.
Tally ERP & Zoho ERP
Tally PrimeTallyConnectorZoho BooksZoho InventoryZoho Commerce
Tally is India's most widely deployed accounting system for SMB retail. Tally's ODBC connector and XML-based API allow bidirectional data exchange with commerce platforms - pushing sales orders, purchase receipts, and payment entries. Zoho's ERP suite (Books, Inventory, Commerce) is API-first and better suited for integration; its REST API covers items, orders, inventory adjustments, and customer management. Advisory covers the integration architecture that keeps Tally or Zoho in sync with the OMS without requiring nightly batch exports and manual reconciliation.
ERP Integration Patterns & Middleware
Async Event QueueIdempotent SyncMuleSoftBoomiAWS EventBridge
The integration pattern matters more than the specific ERP. Synchronous OMS-to-ERP calls make your order flow dependent on ERP uptime. Asynchronous event queues (SQS, EventBridge, Kafka) decouple OMS operations from ERP processing - orders are posted to a queue, the ERP consumes them at its own pace, and failures are retried automatically without affecting the customer checkout flow. Idempotency keys prevent duplicate financial postings on retry. This pattern works across SAP, Oracle, Dynamics, and custom ERPs - the ERP's internal model doesn't dictate the OMS integration architecture.
Finance & Reconciliation Integration
Revenue RecognitionMarketplace SettlementPayment Gateway ReconciliationGST/Tax
Finance integration goes beyond order sync. Marketplace settlement files (Amazon, Flipkart) need to be matched against expected payments per order. Payment gateway transaction records (Razorpay, Stripe, PayU) need to be reconciled against orders in the OMS and against ERP revenue entries. GST/tax data for B2B invoicing needs to flow accurately to the ERP for tax filings. This layer typically surfaces the most discrepancies - and the most value - because manual reconciliation at any commerce volume is unsustainable.
Courier & Logistics
Courier Aggregators &
Last-Mile Architecture
Last-mile logistics is where the customer experience either holds up or falls apart. Courier selection, NDR management, tracking updates, and RTO reconciliation are operational workflows that need to run automatically at scale - not through daily ops team manual work across five different courier portals.
Shiprocket & Multi-Courier Aggregators
Shiprocket is India's dominant courier aggregator, giving access to Delhivery, Bluedart, Ecom Express, XpressBees, and DTDC through a single API. Aggregator integration means one contract, one tracking webhook, and courier auto-selection per order. The trade-off is less control over individual courier SLA enforcement - which matters at scale when you need courier-level performance visibility, not just aggregator-level metrics.
Direct Courier APIs
Direct API integration with Delhivery, Bluedart (DHL), Ecom Express, and XpressBees gives better SLA visibility, priority lanes, and dispute resolution. Delhivery's API covers forward shipping, reverse pickup, surface express, and cross-border. Bluedart is preferred for high-value and time-sensitive shipments. Shadowfax and Ekart dominate hyperlocal and marketplace-mandated fulfilment respectively.
NDR (Non-Delivery Report) Management
NDR - when a delivery attempt fails - is one of the highest-cost events in last-mile logistics. Unmanaged NDR causes RTO (Return to Origin) rates to climb, adding reverse logistics cost and tying up working capital in in-transit inventory. Automated NDR management means: detect the failed attempt, trigger a customer reattempt flow, escalate unresponsive orders to RTO, and log the outcome for courier performance tracking.
Reverse Logistics & Returns Courier
Returns triggered on marketplaces or your own site need a reverse pickup scheduled, a different courier SLA (typically 5–7 days vs 24–48h forward), and a QC check at the warehouse before inventory is re-entered. Reverse logistics APIs are less mature than forward shipping APIs - integration often requires custom webhook handling for pickup confirmation, in-transit tracking, and delivery-to-warehouse events.
Courier Performance & SLA Monitoring
Courier performance varies significantly by zone, weight band, and season. Without per-courier SLA data - delivery rates, NDR rates, RTO rates, average transit times - you're optimising courier selection on cost alone. Building a courier performance layer that feeds real-time data into selection logic means your routing improves automatically as courier performance data accumulates.
Courier Invoice Reconciliation
Couriers bill on actual weight/dimensions which often differ from estimates. Excess weight charges, fuel surcharges, and COD remittance discrepancies need to be reconciled against expected charges per shipment. Manual reconciliation at any meaningful volume is unsustainable. Automated courier reconciliation identifies billing errors, disputes, and remittance delays - typically recovering 2–5% of courier spend in billing corrections alone.
Supply Chain & DMS
Distribution, Supply Chain &
Logistics Architecture
Supply chain architecture in retail and FMCG sits between your OMS and your warehouses, distributors, and 3PL partners. When it's not designed deliberately, gaps appear: inventory that's available in the system isn't at the right fulfilment node, distributor orders aren't reconciled against actual dispatch, and logistics costs are invisible at the SKU or zone level. Here's where I provide advisory across the supply chain stack.
Distribution Management Systems (DMS)
BizomFieldAssistMeraqiYara DMSSAP DMSCustom DMS
DMS platforms manage the primary and secondary sales flow in FMCG and pharma distribution - from company to distributor (primary) and distributor to retailer (secondary). Integration covers order booking via salesperson apps, scheme and discount management, beat planning, distributor inventory visibility, and secondary sales data flowing back into demand planning. Bizom and FieldAssist dominate India's FMCG DMS market; custom-built DMS portals are common in mid-market distribution businesses where off-the-shelf solutions don't fit the channel structure.
Supply Chain Management Platforms
SAP S/4HANA SCMOracle SCM CloudBlue YonderIncreffKinaxis
SCM platforms handle demand planning, procurement, supplier management, and inventory positioning across the fulfilment network. The integration challenge is keeping SCM demand signals in sync with real-time OMS order velocity and warehouse inventory levels - so replenishment decisions are grounded in actual sell-through data, not lagged batch reports. Platform selection, integration architecture, and data contract design between OMS, ERP, and SCM are the advisory areas here.
Warehouse Management Systems (WMS)
Increff WMSVinculum WMSFynd WMSSnapFulfilOracle WMSManhattan
WMS platforms manage physical warehouse operations - inbound receipts, putaway, bin-level inventory, pick-pack-ship workflows, and returns processing. The critical integration is the bidirectional sync between WMS and OMS: the OMS should only release orders to fulfilment when WMS confirms inventory at the bin level, and every pick and dispatch should update OMS order status in real-time. Increff, Vinculum, and Fynd are dominant in India's organised commerce WMS market.
3PL Integration & Fulfilment Networks
Delhivery FulfilmentEcom Express WHXpressBees 3PLShadowfaxFedEx Supply Chain
Third-party logistics providers offer fulfilment-as-a-service - managed warehousing, pick-pack, and last-mile delivery under one contract. The integration complexity is that you're giving a 3PL operational control over inventory you still own. Integration patterns must cover inbound ASN (Advance Ship Notice), GRN (Goods Received Note), inventory visibility APIs, order release, and returns handling - with enough data flowing back to your system to maintain real inventory ownership visibility without depending on the 3PL's reporting portal.
Cold Chain & Specialized Logistics
ColdexSnowmanRivigoCold Chain APIsFEFO Picking
Cold chain logistics adds temperature compliance, short shelf-life inventory management, and expiry-based fulfilment logic on top of standard warehouse and courier flows. FEFO (First Expiry First Out) picking rules, temperature excursion alerts, and compliance documentation are requirements that standard WMS integrations don't cover by default. Applicable to pharma, grocery, fresh produce, and FMCG categories with temperature-sensitive SKUs and regulatory traceability requirements.
Logistics Intelligence & Cost Analytics
Zone AnalysisCost per OrderRoute OptimisationCarrier Benchmarking
Logistics costs typically run 8–15% of GMV in India-market commerce, and most businesses have limited visibility into what's driving those costs at the SKU or zone level. Building logistics analytics means tracking cost-per-shipment by carrier, zone, and weight band; modelling the impact of warehouse positioning on last-mile cost; and identifying which SKUs and channels are above-average cost contributors. This layer typically surfaces significant optimisation opportunities once the data is structured correctly.
Scale-Up & Modernization
Scaling & Modernising Retail Platforms
Without Disrupting Operations
Retail and commerce platforms rarely have the luxury of going offline to modernize. Sale seasons are always coming. Integrations are always live. Teams are always on-call.
The approach I use is bounded and staged. Identify which parts of the platform create the most operational risk or block the most product velocity. Scale and modernize those first, in parallel with what's running. Validate at load, then cut over with confidence.
The goal isn't architectural purity - it's a platform your operations team can trust, your engineering team can deploy reliably, and your business can scale on without operational chaos multiplying with every order of magnitude of growth.
- Marketplace integrations become maintainable, testable, and independently deployable
- Inventory stays accurate across all channels without manual correction
- Order status becomes a single source of truth, not a team consensus
- New channel onboarding takes weeks, not months
- Sale-period and festival scaling is designed for, not discovered during
- Finance reconciliation moves from weekly firefighting to automated verification
- Engineering teams ship product features instead of firefighting connector breakages
- Monolith decomposed into domain services - OMS, inventory, catalog, fulfilment
- Event-driven architecture replacing synchronous chains that break under load
- Cloud-native infrastructure with autoscaling for peak and idle periods
Scale Patterns I Apply
Domain-Driven Decomposition
OMS DomainInventory DomainCatalog DomainFulfilment Domain
Breaking the monolith by bounded context rather than technical layer. OMS handles order lifecycle. Inventory owns stock positions and movements. Catalog owns product data. Fulfilment owns WMS, courier, and last-mile. Each domain deploys independently and owns its data store.
Event-Driven Integration Backbone
KafkaSQS/SNSEventBridgeRabbitMQ
Replacing synchronous API chains with event streams. Order placed → inventory reserved → fulfilment triggered → marketplace notified - all asynchronous with guaranteed delivery. This is what allows peak traffic spikes to be absorbed rather than causing cascading failures.
Read/Write Separation & Caching
Redis CacheRead ReplicasCQRS PatternCDN Edge
Separating the high-read paths (catalog display, inventory check, order status) from write paths (order creation, inventory updates). Read replicas for reporting and analytics queries. Redis caching for catalog and pricing layers. CDN edge for static and semi-static content.
Cloud-Native Infrastructure & Autoscaling
ECS/EKSLambdaAuto Scaling GroupsSpot Instances
Container-based deployments with horizontal pod autoscaling triggered on queue depth and request rate - not just CPU. Separate scaling profiles for sale-event bursts vs steady-state. Cost-optimised with spot/preemptible nodes for batch processing workloads like reconciliation and report generation.
AI Innovation & Implementation
AI That Earns Its Place
in Retail Operations
The retail AI applications that deliver real value are grounded in operational data - order history, inventory positions, customer behaviour, and fulfilment events. These are the implementations worth building seriously, covering prediction engines, recommendation systems, and AI-powered operations platforms.
Prediction Engine
Demand prediction at the SKU-location level using OMS sell-through velocity, seasonal patterns, and promotional signals. Stockout prediction surfacing at-risk SKUs before they hit zero. Replenishment recommendation grounded in real lead times and safety stock policy - moving from reactive reordering to predictive inventory management.
Recommendation Engine
Personalised product recommendations, cross-sell, and upsell powered by purchase history, browsing behaviour, and basket analysis. Replacing static "frequently bought together" rules with ML-driven suggestions that adapt per customer segment. Also applicable to internal catalog recommendations - surfacing the right SKUs for marketing campaigns, bundling, and pricing decisions.
Order & Warehouse Management Engine
AI-optimised order routing that selects the best fulfilment node based on inventory position, last-mile cost, delivery SLA, and carrier performance - not static nearest-warehouse rules. WMS picking path optimisation that reduces pick time per order. Dynamic slotting recommendations for warehouse layout based on SKU velocity and co-pick frequency patterns.
Customer Support Automation
Handling order status queries, return and exchange requests, and delivery exception questions without routing everything to a human agent. Grounded in your actual order data, not generic responses.
Internal Operations Copilot
Operations teams querying inventory levels, order statuses, and fulfilment exceptions using natural language - rather than pulling reports from five different systems at once.
Catalog Enrichment Workflows
Using LLM workflows to normalise product descriptions, extract attributes, generate marketplace-ready content, and maintain catalog quality at scale - reducing manual effort significantly across thousands of SKUs.
Anomaly Detection in Operations
Identifying unusual patterns in inventory movements, order failures, courier performance, and payment discrepancies before they become business-impacting problems that surface as customer complaints.
Demand & Operational Intelligence
Surfacing signals across sales, inventory, and fulfilment data to help operations teams make faster decisions - without requiring a full data science function to maintain. Natural language analytics over your commerce data.
Who This Is For
The Businesses That
Reach Out to Me
Retail Founders & CEOs
Your commerce platform works - until it doesn't. During a sale, during rapid growth, or when you add a new channel and everything starts breaking at the edges. You need someone who understands the system coordination problem, not just the frontend.
Ecommerce & D2C Leaders
Scaling D2C across channels means dealing with marketplace feeds, inventory sync, logistics APIs, and customer experience consistency simultaneously. These are coordination and architecture problems before they're operational ones.
Commerce SaaS Companies
Building a platform that retail businesses rely on means your architecture is their architecture. Platform stability, multi-tenant design, integration reliability, and API governance all need to be right before you can grow sustainably.
Teams Modernizing Legacy Retail Stacks
A monolithic platform built for 100 orders a day is now processing 10,000 - and it shows. You need a migration plan that doesn't require taking the platform offline or rebuilding everything from scratch.
Why This Matters
I Understand Retail Complexity
Beyond the Storefront
The retail challenge most people underestimate is system coordination. Revenue reliability depends on inventory staying accurate, orders moving cleanly through fulfilment, payments reconciling correctly, and integrations holding up when individual systems have downtime. Each one of those is an architecture problem before it's an operations problem.
I've worked inside commerce platforms at the point where these coordination problems become business-critical. The decisions I help teams make are grounded in having navigated that complexity - not in theory about how distributed commerce should work.
20+
Years in Technology Leadership
31+
Products Shipped to Production
35M+
API calls/day at peak scale
5
India, UAE, Maldives, USA & Canada
FAQ
Common Questions
What kind of retail and commerce platforms have you worked with?
B2B and B2C commerce platforms, D2C brand stacks, marketplace seller platforms, omni-channel retail systems, and commerce SaaS products. Across India and with teams building for international markets, including high-transaction environments during sale periods.
Can you help with a specific integration - marketplace, ERP, or logistics?
Yes. If you're dealing with a specific connectivity challenge - unreliable marketplace feeds, ERP sync issues, logistics API failures, or building a new integration cleanly - that's a productive thing to work through. Bring the specifics and we can get into it immediately.
Do you work on the architecture side or the delivery side?
Both. For some teams I provide architecture guidance and directional input. For others I'm more actively involved in defining integration contracts, technical standards, and helping engineering leads navigate delivery decisions under pressure.
We're mid-way through a modernization that's gone sideways. Can you help?
Yes. This is actually a common entry point. If a migration is behind schedule or producing more fragility than it's removing, an independent read on what went wrong and what the realistic path forward is can be very useful - and faster to act on than a full restart.
Can you work with teams outside India?
Yes. I've worked with teams remotely across UAE, the US, and other markets. Commerce architecture conversations work well in structured sessions and asynchronous communication across time zones.
We sell on Amazon, Flipkart, and Meesho simultaneously. Inventory sync is a constant problem. Where do we start?
The first question is whether you have a single authoritative inventory system or whether each marketplace is effectively its own inventory record. If it's the latter, the fix isn't a better sync tool - it's establishing a central inventory master that all channels read from and write to. Once that's clear, we can look at the specific failure modes: are you seeing oversells, update lag, or reconciliation discrepancies? Each has a different root cause and a different fix.
How do you approach POS and ERP integration for omni-channel retail?
The pattern that works is treating the POS as a transaction event source, not a data store. Every sale from Pine Labs, Shopify POS, or Ginesys should emit an event that the central OMS and ERP consume - inventory deducted, sale recorded, loyalty updated - in near real-time. Batch-at-end-of-day sync is a legacy pattern that makes omni-channel inventory genuinely inaccurate during business hours. The integration work is straightforward; the harder part is usually getting the ERP team to accept event-driven updates rather than scheduled batch imports.
Our RTO rate is high and it's eating into margins. Is that an operations problem or an architecture problem?
Usually both, but they compound. Architecturally: if NDR events from Delhivery, Ecom Express, or Shadowfax aren't being detected and acted on automatically, failed deliveries silently convert to RTOs. Operationally: address verification at checkout, COD order validation, and proactive customer communication after first failed attempt each reduce RTO without any systems work. In my experience, fixing the automated NDR detection first gives you the data to understand what's driving RTO - and whether it's a courier, a product category, a geography, or a customer segment issue.
How long does building a proper multi-marketplace integration layer take?
A properly abstracted marketplace integration layer - where adding a new channel is implementing a shared interface rather than building a new custom connector - typically takes 8–14 weeks for the first two or three marketplaces, depending on API maturity. Amazon SP-API is well-documented and stable. Flipkart is reasonable. Meesho has matured significantly. Fashion marketplaces (Myntra, Nykaa) require additional catalog normalisation work that adds time. The payoff is that the fourth and fifth marketplace integrations are significantly faster once the abstraction layer is in place.
What's the best way to start?
Book a 30-minute session using the calendar on the strategy page. Come with one specific platform challenge - inventory sync, marketplace reliability, POS integration, courier NDR, ERP connectivity. The more specific the problem, the more useful the conversation.