Mayur Patel
Mar 16, 2026
6 min read
Last updated Mar 16, 2026
Retail distribution businesses still operate on fragmented systems. Field sales teams report activity through spreadsheets or WhatsApp. Distributor orders move through calls and manual records. Retailer data remains scattered across tools. For industries like FMCG, pharmaceuticals, consumer goods, and building materials, this lack of visibility slows decisions, weakens sales execution, and creates operational blind spots across the distribution network.
This case study examines how BeatRoute approaches this challenge. BeatRoute is a B2B SaaS platform designed to digitise distributor-led retail sales operations. It connects brands, distributors, and retailers through a single system that supports sales automation, order management, and real-time sales visibility. Continue reading to understand how this platform redesign addresses the structural problems of retail sales management.
Read more: Why Teams Optimize Conversion Rate Instead of Revenue
BeatRoute operates in industries where sales move through distributor networks rather than direct channels. Sectors like FMCG, pharmaceuticals, consumer goods, and building materials depend on large field sales teams that interact with distributors and retail stores daily. Brands need visibility across this chain, but operational data is often scattered across spreadsheets, phone calls, and informal reporting systems.
BeatRoute is a B2B SaaS platform built to modernise this distribution model. The platform centralises field sales operations by connecting brands, distributors, and retailers in a single digital system. It enables sales force automation, order management, route planning, and performance tracking while replacing fragmented reporting with real-time operational visibility across retail sales networks.
Read more: Why Some Lead Form Fields Kill Conversions
The project’s North Star was to improve visibility and operational control across distributor-led retail sales networks. The objective was to design a platform that helps brands, distributors, and field sales teams operate from the same system rather than fragmented tools.
Read more: From Custom Builds to 60 Stores: BVB Media eCommer Platform Story
Retail distribution operates through a multi-layered network of stakeholders. Brands depend on field sales teams to manage retailer relationships, while distributors handle order fulfillment and inventory movement across regions. In many companies, these activities still run through disconnected tools such as spreadsheets, phone calls, and informal reporting channels. This fragmented setup makes it difficult for businesses to track sales performance, monitor distributor activity, or maintain consistent retailer engagement.
The complexity increases as distribution networks scale. Sales teams operate across multiple territories, distributors manage inventory and payments, and retailers expect timely order fulfilment. Without a unified system, operational data remains scattered across different sources, slowing decision-making and creating gaps in visibility. BeatRoute addresses this structural challenge by designing a platform that centralises sales operations and connects all stakeholders in the retail distribution ecosystem.
Read more: How to Optimize Demo Request Flows Without Disrupting Sales Infrastructure
The engagement focused on designing the user interface and experience for BeatRoute’s sales enablement platform. The scope was limited to product design, to create clear workflows for retail sales operations used by multiple stakeholders in distributor-led sales networks.
Read more: How Linearloop Built a Zero Loss ERP for a Gold Refinery: Gold VGR ERP Case Study
For the client, success meant improving how retail sales operations function day to day. The platform needed to support stronger sales execution by giving field teams clearer workflows, faster order handling, and better visibility into sales activity across distributor networks. Operational efficiency, rather than feature complexity, was the primary benchmark.
The design also had to support smoother collaboration between distributors and retailers. Interfaces were structured around real operational workflows such as order placement, account tracking, and sales reporting. Instead of abstract product features, the focus was on building tools that reflect how retail distribution actually works across field teams, distributor partners, and retail stores.
Read more: Modern AI Data Stack Architecture Explained for Enterprises
Retail distribution platforms must support multiple stakeholders working within the same operational system. The BeatRoute design needed to accommodate three core user groups, each with distinct responsibilities, workflows, and expectations from the platform.
Read more: From Manual Coordination to Automated Logistics: Sarthitrans Case Study
The design focused on creating clear operational interfaces for core retail sales workflows. Each module was structured to support a specific function within the distributor-led sales ecosystem, ensuring that field teams, distributors, and retailers could manage sales activities from a single system.
| Platform module | Operational role |
| Reward points management | Displays reward points earned by users and enables redemption through a structured interface, supporting incentive programs designed to motivate sales teams and channel partners. |
| Order management interface | Provides mobile-friendly workflows for creating, tracking, and managing retailer orders, enabling field sales representatives to place and monitor orders directly during store visits. |
| Statement of accounts dashboard | Allows distributors and traders to view transaction records, track due payments, monitor credit notes, and review payment history through filtered financial statements. |
| Sales activity visibility | Presents sales activity data and performance insights, enabling brands to monitor field sales operations and track retail engagement across their distribution network. |
The project focused on interface design and user experience architecture rather than engineering implementation. The design environment was structured to support collaborative workflows, iterative feedback, and clear handoff specifications for product development teams.
Read more: Instream Case Study: Modernizing a Legacy CRM Without Downtime
The design approach focused on building a unified operational system rather than a collection of isolated features. The goal was to structure the platform around real retail workflows so brands, distributors, and retailers could operate within the same visibility layer. Execution followed an Agile design process with iterative refinement and stakeholder collaboration.
The platform was conceptualised as a connected ecosystem where brands, distributors, and retailers interact through shared workflows. Interfaces were designed to reflect real operational relationships across the retail distribution chain rather than independent feature modules.
Design decisions prioritised workflow clarity. Sales activities, order management, and financial tracking were structured into intuitive interfaces that allow stakeholders to access operational data without relying on fragmented tools or manual reporting.
The project followed an Agile design approach where interface prototypes were continuously refined through structured iterations. Each cycle focused on improving usability, simplifying workflows, and aligning the product experience with field sales operations.
Design reviews were conducted with client stakeholders throughout the process. Feedback loops ensured the interface aligned with real retail distribution workflows and operational expectations before the final design handoff.
Read more: How to Deploy Private LLMs Securely in Enterprise
No third-party integrations were included during this engagement. The project scope was limited to designing the user interface and user experience architecture for the BeatRoute platform. The design focused on structuring core product workflows such as sales activities, order management, and account visibility. Integration with external systems was not part of the design phase, allowing the work to concentrate on interface clarity and operational usability.
The design was received positively by the client and key stakeholders involved in the project. The interface structure aligned with the operational workflows used in retail distribution, making it easier to visualise how field sales teams, distributors, and retailers would interact with the platform.
Stakeholders particularly appreciated the clarity of the workflows and the usability of the interface. The design translated complex retail sales operations into structured screens and dashboards, enabling a clearer understanding of how the platform could support real-world sales activities.
Read more: RAG vs Fine-Tuning: Cost, Compliance and Scalability Explained
Retail distribution networks operate across multiple stakeholders, territories, and operational workflows. Without a unified system, brands struggle to maintain visibility across field sales activities, distributor coordination, and retailer engagement. BeatRoute demonstrates how thoughtful product design can bring these fragmented processes into a single operational platform, enabling clearer workflows, better data visibility, and more structured retail sales management.
If you are building a B2B platform that must support complex operational ecosystems, the design approach becomes critical. At Linearloop, we work with teams to design scalable product experiences for systems that involve multiple users, workflows, and operational dependencies. If you are planning a similar transformation, reach out to Linearloop to explore how the right design architecture can support your product vision.
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 Co-founders with Linearloop founder discussing multiple projects
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
BVB Media founder checking on the web development plan.
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
Team churning out the best ideas for BVB Media projects
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
