How Saffro Mellow Scaled with API-First D2C Architecture

We transformed Saffro Mellow Coatings & Resins from a traditional paint manufacturer into a tech-enabled commerce and logistics system with real-time driver mapping, payment-state clarity, and a configurable loyalty engine. This was a backend-first operating layer that unified D2C sales, warehouse fulfillment, rider workflows, and compliant communication into one modular system.

The North Star was under operational control. Faster order allocation, transparent rider payments, accurate location-based driver assignment, and repeat purchases driven by loyalty, all without developer dependency for day-to-day admin decisions. We built an API-first architecture designed to scale across locations, handle partial payments cleanly, and support future warehouse expansion without rearchitecture.

Saffro Mellow Coatings & Resins is a paint manufacturing and fulfillment business operating in a distributor-led ecosystem and expanding into direct-to-consumer commerce. The founder wanted to reduce dependence on intermediaries, gain tighter control over margins, and build a structured digital layer to manage products, payments, warehouses, and delivery workflows without operational chaos.

• Manufactures and sells paint products with weight-based variants (1kg, 2kg, 5kg)
• Manages warehouse-level inventory and location-based dispatch
• Operates rider-based last-mile delivery
• Handles prepaid, partial, and COD payments
• Needed loyalty, referral, and DLT-compliant communication integration

The North Star was operational clarity at scale. The founder wanted a structured system in which orders moved predictably from checkout to warehouse allocation to rider assignment, without confusion about payments, locations, or responsibilities. Every decision was anchored to reducing allocation delays, eliminating payment ambiguity for riders, and ensuring that each warehouse and driver operated within clearly defined digital boundaries.

At the same time, the system had to support repeat commerce. That meant building a configurable loyalty and referral engine that could drive customer retention without engineering intervention for every rule change. The objective was simple but non-negotiable: 

• Faster fulfillment
• Transparent payments
• Scalable multi-location architecture
• Admin-level control without developer dependency

This system had to operate inside real-world limits, not ideal conditions. Every architectural decision was shaped by regulatory, financial, and operational constraints that could not be bypassed.

• All customer communication had to comply with India’s DLT regulations, which meant pre-approved SMS templates, strict header mapping, and zero tolerance for messaging errors that could block transactional updates.
• Razorpay integration had to support prepaid, partial, and COD flows while maintaining accurate payment-state synchronization across admin and rider interfaces.
• The platform had to be mobile-first, as riders and operational teams depended heavily on handheld devices for real-time updates.
• Budget sensitivity required modular development without overengineering, ensuring scalability without unnecessary infrastructure overhead.
• The backend architecture had to support future multi-location and multi-warehouse expansion without structural rewrites or data model compromises.

The client needed orders to move from checkout to warehouse allocation to rider assignment without manual intervention or reconciliation confusion. If a rider opened the app, the payment state had to be accurate, whether the order was prepaid, partially paid, or COD, because even small discrepancies would erode trust instantly.

Success also meant administrative independence. The founder wanted the ability to configure referral points, manage FAQs, activate or deactivate features, and control operational flows without depending on developers for every adjustment. 

The most fragile layer of this system was payment-state synchronization. Partial payments processed through Razorpay had to reflect instantly and accurately across the admin dashboard and the rider PWA, because any mismatch between what was collected online and what a rider expected to collect at delivery would create operational friction and distrust. We had to design a payment-state-aware logic that handled prepaid, partial, and COD flows without edge-case leakage.

Multi-location driver mapping was equally sensitive. Each driver and vehicle had to be strictly associated with defined warehouse locations, and data integrity had to prevent cross-location misallocation. Add weight-based product variants and DLT-approved messaging constraints, and the margin for error became extremely narrow.

The technology stack was selected for modularity, scalability, and clean API contracts, because this system had to support commerce, logistics, payments, and loyalty without collapsing under future expansion.

• Backend was built on a headless commerce architecture similar to Medusa, using Node-based services with GraphQL APIs and PostgreSQL for structured relational data management.
• Frontend included a customer-facing mobile-first application, a rider PWA for delivery workflows, and a configurable admin dashboard for operational control.
• Infrastructure was deployed on AWS with structured API versioning and scalable server environments.
• Payments were integrated through Razorpay, including support for BNPL and partial payment logic.
• Communication layers included a DLT-compliant SMS gateway and NOVU-powered email workflows.

This system was designed as a modular operating layer in which commerce, logistics, payments, and loyalty could function independently while remaining structurally connected.

• API-first modular architecture: We defined clean service boundaries and API contracts before UI development, ensuring that commerce, logistics, and loyalty modules could scale or evolve without breaking dependent workflows.
• Config-driven loyalty engine: Reward points, referral values, and activation states were controlled from the admin panel, allowing business experimentation without engineering redeployment.
• Payment-state-aware rider logic: The rider interface dynamically adapts based on prepaid, partial, or COD status, eliminating ambiguity around what needs to be collected at delivery.
• Driver-location mapping module: Drivers were strictly mapped to defined warehouse zones, with relational constraints that prevented cross-location assignment errors.
• Vehicle-location association layer: Vehicles were digitally bound to operational regions, ensuring logistical clarity and traceable dispatch control.
• Feature toggle system: Core modules could be activated or deactivated through structured flags, allowing phased rollout and controlled experimentation.
• Scalable order lifecycle engine: Orders moved through clearly defined states with versioned APIs, reducing redundancy and maintaining data integrity across systems.

We followed a backend-first development approach because the complexity of payments, logistics, and loyalty logic demanded structural clarity before interface work began. API contracts were defined and reviewed before UI implementation, ensuring that every screen consumed predictable, versioned endpoints rather than loosely defined responses. This reduced rework and prevented frontend dependencies from dictating core system behavior.

Execution was structured in feature-wise Agile iterations with weekly milestone-based deliveries. Each sprint focused on a complete functional block, such as driver mapping or partial payment handling, rather than fragmented UI elements. This approach ensured that high-risk modules were validated early, edge cases were surfaced quickly, and integration points with Razorpay and DLT messaging were tested in controlled cycles.

This platform relied on tightly controlled integrations that could not afford failure. Razorpay powered prepaid, partial, COD, and BNPL flows, with validated webhooks ensuring real-time payment-state accuracy across admin and rider systems. Payment reconciliation was engineered as core logic to prevent misreporting or delivery-side confusion.

We integrated a DLT-compliant SMS gateway for regulatory messaging and NOVU for transactional emails, both mapped to structured event triggers. The system ran on AWS with scalable environments, while Medusa-based commerce services were extended through clean, versioned APIs to maintain consistency and data integrity across modules.

The impact of this system was measured through operational efficiency, payment clarity, and structural control rather than surface-level metrics, because the primary objective was to eliminate friction inside fulfillment and financial workflows.

• Reduced order allocation time: Structured driver-location mapping and automated assignment logic significantly decreased manual coordination between warehouse managers and delivery teams.
• Improved payment transparency for riders: Real-time payment-state visibility eliminated confusion between prepaid, partial, and COD orders, reducing reconciliation disputes.
• Fewer COD-related operational errors: Clear payment detection logic minimized incorrect collection attempts and post-delivery adjustments.
• Increased repeat purchases through loyalty: Configurable referral and reward mechanisms encouraged customers to return without requiring constant promotional campaigns.
• Greater administrative independence: Feature toggles and configurable modules reduced dependency on developers for operational changes.
• Scalable multi-location readiness: The modular backend architecture positioned the business for warehouse expansion without structural rewrites.

What makes this project special is the structural shift it enabled. A traditional paint manufacturer moved from distributor-led operations to a digitally orchestrated commerce and logistics system where payments, drivers, warehouses, and loyalty mechanisms operate within defined boundaries. We redesigned the operational backbone to prevent scale from introducing chaos.

This system was built modularly from day one, with reusable patterns for driver mapping, payment-state logic, and configurable rewards that can extend into future multi-warehouse expansion. It proves that even industries considered offline-heavy can run on a structured, API-first architecture without sacrificing operational clarity or compliance discipline.

We continue to refine performance, expand reporting visibility, and prepare the system for tier-based loyalty, wallet functionality, multi-warehouse logic, and route optimization. Each iteration strengthens the modular architecture rather than layering shortcuts, ensuring that scale is absorbed structurally and not patched operationally.

If you are running a traditional business that depends on distributors, manual reconciliation, or loosely connected systems, the shift requires more than a storefront. It requires a commerce and logistics operating layer built with discipline from day one. If that transformation is on your roadmap, we should talk.