Mayur Patel
Feb 18, 2026
5 min read
Last updated Feb 20, 2026
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.
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:
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.
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.
This system was designed as a modular operating layer in which commerce, logistics, payments, and loyalty could function independently while remaining structurally connected.
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.
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.
Mayur Patel, Head of Delivery at Linearloop, drives seamless project execution with a strong focus on quality, collaboration, and client outcomes. With deep experience in delivery management and operational excellence, he ensures every engagement runs smoothly and creates lasting value for customers.
From Custom Builds to 60 Stores: BVB Media E-commerce Platform Story
BVB Media delivers customised e-commerce solutions for businesses across the Netherlands. As their client base expanded, the traditional approach of building every store from scratch started creating operational friction. Development cycles became longer, engineering effort was repeatedly duplicated, and maintaining consistency across multiple client implementations became increasingly complex. The team needed a way to scale their services without rebuilding the same infrastructure for every new project.
This case study explains how we partnered with BVB Media to design and build FTLShop, a reusable e-commerce framework engineered for scalability. The solution combined a modular frontend architecture with a custom Node.js middleware layer to bridge the frontend and the existing PHP backend platform. The result was a framework capable of supporting 50–60 e-commerce stores while significantly improving delivery speed and architectural stability.
Read more: How Linearloop Built a Zero Loss ERP for a Gold Refinery: Gold VGR ERP Case Study
BVB Media builds customised e-commerce platforms for businesses across the Netherlands. As their client portfolio expanded, the traditional delivery model began to show its limits. Every new store required a separate codebase, repeated engineering effort, and longer delivery cycles. This approach slowed down onboarding for new clients and created unnecessary complexity for the development teams managing multiple implementations.
To solve this, the focus shifted from individual projects to platform architecture. Instead of building each store independently, we worked with BVB Media to design FTLShop, a reusable e-commerce framework that could support multiple client deployments from a common foundation. The objective was straightforward: Create a scalable architecture that reduces repeated development work while allowing each client implementation to remain flexible and customisable.
Read more: Modern AI Data Stack Architecture Explained for Enterprises
The idea was to move from isolated projects to a structured framework called FTLShop. This framework would act as a reusable base architecture, enabling faster deployments while maintaining consistent performance across stores. The focus was on building a system that could scale operationally as the client base expanded.
Read more: From Manual Coordination to Automated Logistics: Sarthitrans Case Study
Building a reusable e-commerce framework meant working within several technical and operational limits. The system had to integrate with existing infrastructure while supporting future scalability.
These constraints shaped the architectural decisions and required disciplined engineering choices throughout the project:
Read more: Instream Case Study: Modernizing a Legacy CRM Without Downtime
For BVB Media, success was not measured by launching a single platform. The expectation was to create an architecture that could support continuous client onboarding without repeating the same development effort. The system needed to enable faster delivery timelines while maintaining a consistent technical foundation across every implementation.
The framework also had to support scale. BVB Media wanted a solution capable of powering 50–60 e-commerce stores while keeping performance stable across deployments. At the same time, development complexity could not grow with every new client. The platform had to support expansion while keeping engineering effort predictable and manageable.
Read more: How to Deploy Private LLMs Securely in Enterprise
Building a reusable framework on top of an existing ecosystem introduced several engineering challenges. The system had to support modern frontend architecture while remaining compatible with legacy backend infrastructure. At the same time, it needed to remain stable across multiple store deployments.
Read more: RAG vs Fine-Tuning: Cost, Compliance and Scalability Explained
The framework required a technology stack that could support modular frontend development while integrating smoothly with the existing backend platform.Each technology was selected to support a specific architectural requirement within the FTLShop framework.
| Technology | Role in the architecture |
| Pawjs | Served as the primary framework for building the frontend architecture. It enabled modular component development and supported scalable e-commerce interfaces across multiple client stores. |
| Node.js | Used to build the middleware layer that handled communication between the frontend system and the existing backend services. |
| TypeScript | Provided type safety and maintainable code structure within the middleware layer, improving long-term code reliability. |
| Redux | Managed frontend state efficiently, ensuring predictable data flow across the application. |
| CSS | Used for building consistent and reusable styling components within the frontend system. |
| Google Analytics | Enabled behavioural tracking and performance insights across client e-commerce stores. |
| Google Tag Manager | Managed marketing and analytics tags without requiring code changes in the core system. |
| A/B Testing Tools | Allowed teams to run conversion experiments and optimise user journeys across stores. |
| Robin Chat | Integrated customer communication capabilities directly into the platform for live engagement. |
The team designed a layered architecture that separated responsibilities across frontend, middleware, and backend systems. This approach allowed each layer to evolve independently while maintaining stable communication between components.
The platform followed a structured architecture consisting of four layers: Frontend interface, Node.js middleware, PHP backend services, and the underlying platform layer. Each layer had a clearly defined role, which prevented tight coupling between systems. This separation allowed teams to scale the platform without creating dependencies that could affect stability across multiple client implementations.
The frontend architecture was designed to be modular and reusable. Components were structured so that interface elements, workflows, and state management patterns could be reused across different client stores. This ensured that new implementations could be deployed faster while maintaining a consistent user experience and maintainable code structure.
A custom Node.js middleware layer was developed to manage communication between the frontend and the existing PHP backend systems. The middleware acted as an API orchestration layer, handling request routing, response formatting, and integration logic. This abstraction prevented direct dependency between the frontend and backend systems, improving flexibility and maintainability.
The middleware layer allowed both sides of the system to evolve independently. Frontend teams could implement new features without modifying backend services, while backend teams could maintain platform logic without impacting the frontend architecture. This decoupling was essential for maintaining stability across multiple client deployments.
The architecture also introduced a custom package called BVB Shop, which centralised business logic and API handling. Instead of duplicating logic across implementations, this package provided a reusable foundation for core e-commerce operations. It ensured consistency across stores and simplified maintenance as the number of client implementations grew.
Read more: Executive Guide to Measuring AI ROI and Payback Periods
The project followed an Agile development approach with structured sprint cycles. Work was organised into incremental deliverables so the architecture could evolve while maintaining system stability. Each sprint focused on building specific framework components, validating integrations, and resolving dependency issues before moving to the next layer of development.
Responsibilities were clearly divided between the teams. Linearloop focused on the frontend architecture and the Node.js middleware layer that connected the system. BVB Media’s in-house team handled the backend services, platform logic, and infrastructure management. This separation allowed both teams to work within their areas of expertise while maintaining a consistent architectural direction.
Since the teams were distributed across different regions, structured communication became essential. Clear API contracts were defined to ensure reliable interaction between system layers. Regular technical discussions and planning sessions helped align development priorities, resolve integration issues early, and maintain coordination across the frontend, middleware, and backend environments.
Read more: Why Enterprise AI Fails and How to Fix It
The platform integrated several external tools to support analytics visibility, marketing operations, and customer engagement across multiple client stores. These integrations ensured that every implementation built on the framework could track performance, run experiments, and interact with users without requiring additional custom development.
| Integration Tool | Role in the platform |
| Google Analytics | Implemented to capture behavioural data across stores. It provided visibility into traffic patterns, user journeys, and engagement metrics, helping teams understand how visitors interact with different e-commerce implementations. |
| Google Tag Manager | Enabled centralised management of tracking scripts and marketing tags. This allowed teams to update analytics configurations without modifying the core platform code. |
| A/B Testing Tools | Integrated to support experimentation across storefronts. Teams could test layout changes, messaging variations, and conversion flows to improve user engagement and purchasing behaviour. |
| Robin Chat | Added live communication functionality within the storefront. This allowed businesses to interact directly with customers, answer queries, and improve customer engagement during browsing sessions. |
The framework shifted BVB Media’s delivery model from isolated project builds to a scalable platform capable of supporting multiple client implementations. The architecture enabled faster deployments, reduced repeated engineering work, and provided a stable foundation for expanding the client portfolio.
Read more: Why Data Lakes Quietly Sabotage AI Initiatives
The framework delivered the operational stability BVB Media needed to scale its e-commerce services. Stakeholders recognised the value of moving from one-off builds to a reusable architecture that could support multiple client implementations. The platform improved delivery speed, reduced repeated engineering work, and created a consistent technical foundation for managing dozens of live stores.
The collaboration also evolved into an ongoing technical partnership. The framework continues to be maintained and supported as new client implementations are added. Both teams remain aligned on improving the platform architecture, ensuring that the system continues to support BVB Media’s growing e-commerce client base.
Read more: Why Executives Don’t Trust AI and How to Fix It
BVB Media’s shift from individual e-commerce builds to a reusable framework fundamentally changed how they deliver digital commerce solutions. By introducing the FTLShop architecture, the team created a scalable system that supports dozens of client stores while maintaining stability and development efficiency. The modular frontend, middleware-driven integration, and reusable business logic layer together formed a foundation that allows the platform to grow without increasing engineering complexity.
Projects like this demonstrate the value of architecture-first thinking in modern digital platforms. When systems are designed for reuse and scalability, businesses can expand faster without compromising technical quality. If your organisation is facing similar scaling challenges in platform development, the Linearloop team can help you design and build the right architecture for long-term growth.
Mayur Patel
Mar 10, 20266 min read
How Linearloop Built a Zero-Loss ERP for a Gold Refinery: Gold VGR ERP Case Study
When every milligram carries financial weight, manual tracking becomes a liability. VGR Gold needed more than a basic ERP. They needed a precision system that could eliminate manual gold tracking, digitise the entire refinery lifecycle, and ensure stage-wise traceability across melting, assaying, refining, casting, and recovery. The objective was to protect high-value assets through system architecture.
Linearloop built a refinery-grade ERP with a precision recovery engine at its core, designed to track residual particles, enforce controlled workflows, and provide real-time visibility across every stage. This case study breaks down how we engineered that system under tight constraints, extended platform capabilities, and delivered a zero-loss operational framework. Read on to see how we helped Gold VGR ERP move from manual processes to milligram-level control.
Read more: From Manual Coordination to Automated Logistics: Sarthitrans Case Study
VGR Gold is a Dubai-based gold refinery operating in a high-precision, multi-stage refining environment. Their workflow spans raw material intake, melting, assaying, refining, casting, and final recovery, each stage directly impacting weight, purity, and financial value. The business handles high-value material daily, where even microscopic discrepancies can translate into measurable loss.
The operating environment is accuracy-critical and regulatory-sensitive. Every batch must be traceable, documented, and verifiable across stages. Process deviations are not just operational issues. Instead, they carry financial and compliance implications. VGR needed systems that matched the precision of their physical operations.
Read More: Instream Case Study: Modernizing a Legacy CRM Without Downtime
Automation was not the goal. Precision was. VGR Gold needed a system that could account for every gram moving through the refinery, eliminate blind spots between stages, and replace manual reconciliation with system-enforced accuracy. The North Star was operational control at milligram-level fidelity.
The system had to be delivered fast, perform flawlessly, and operate in a zero-error environment. Engineering decisions had to balance speed with precision, without compromising traceability or security.
Read More: How Saffro Mellow Scaled with API-First D2C Architecture
Success was defined by operational trust. VGR needed a system that removed manual dependency, enforced accuracy at every stage, and created controlled visibility across the refinery lifecycle.
The complexity sat in the logic layer, where calculation errors, workflow gaps, or data inconsistencies could directly translate into financial risk. Every engineering decision had to protect traceability and precision.
Read more: The Hidden Cost of Trade Discounts on Business Growth
The stack was selected for control, extensibility, and speed of execution. We used Directus as the operational backbone and extended it where refinery-specific logic required deeper customisation. The architecture remained lightweight but precision-focused.
| Layer | Technology | Purpose |
| Backend & CMS | Directus | Core data management layer for refinery workflows, collections, and operational logic extensions |
| Frontend | Vue.js | Built stage-wise tracking interface aligned to refinery operations |
| Database | Directus-managed database | Centralised storage for batch data, recovery calculations, and documentation mapping |
| Authentication & Access | Directus RBAC + custom logic | Enforced stage-based permissions and controlled workflow transitions |
| Version Control | GitHub | Managed source control, deployment workflows, and iterative development cycles |
The architecture was designed around one principle: trace every gram, at every stage, without breaking data integrity. Instead of layering features on top of a generic ERP, we structured the system around refinery flow, ensuring stage transitions, weight calculations, and reporting logic were deeply interconnected and scalable.
Read more: Why Data Lakes Quietly Sabotage AI Initiatives
The timeline was fixed but the scope was complex. Execution required speed without sacrificing calculation accuracy or architectural integrity. We structured delivery around tight feedback loops and disciplined iteration to maintain control under pressure.
Read more: How to Deploy Private LLMs Securely in Enterprise
The ERP replaced fragmented manual tracking with a centralised, stage-driven system. Every refinery phase now operates within a controlled workflow where data propagates with validation.
Manual logs and spreadsheet reconciliations were eliminated. Batch entries, weight transitions, and recovery calculations are system-enforced, reducing operational gaps and dependency on cross-verification.
Stage-level visibility is real time. Managers can track batch progression, weight evolution, and residual quantities instantly. The recovery module calculates residual gold at each phase and updates reports dynamically, ensuring milligram-level traceability.
The platform also creates a scalable base for Phase 2:
Live metrics will follow post-launch, but structurally, the shift is clear: Faster workflows, reduced waste, stronger retention accuracy, and tighter operational control.
Read more: RAG vs Fine-Tuning: Cost, Compliance, and Scalability Explained
The leadership team validated the recovery logic, stage transitions, and reporting structure during simulation cycles. They highlighted three areas of impact:
Operational teams responded positively to the stage-aligned interface. The workflow mirrors physical refinery movement, reducing friction during adoption. Role-based controls were particularly appreciated, as they introduced structured accountability without slowing execution.
We remain actively involved post-deployment. The engagement has transitioned from build phase to optimisation and expansion. Phase 2 is already structured around controlled enhancement rather than feature expansion for its own sake.
Phase 2 roadmap includes:
GOLD VGR ERP demonstrates what happens when operational risk is addressed through system architecture. By replacing manual reconciliation with stage-aware workflows and milligram-level recovery logic, VGR moved from ledger-based tracking to a controlled, intelligent refinery platform. Precision became structural. Traceability became enforceable. High-value material handling is now backed by engineered accountability.
If your operations depend on accuracy, compliance, and zero-loss tracking, the solution is not another tool. it is architecture-first thinking. Linearloop builds systems designed for precision environments where mistakes are expensive. If you are ready to modernise critical workflows with the same level of control, let’s talk.
Mayur Patel
Mar 3, 20266 min read
