How I Built Drs Kart: Building a B2B Medical Equipment Marketplace with React, Vite and Supabase

Building a marketplace is very different from building a simple website. A marketplace needs to handle multiple types of users, different workflows, product listings, communication, authentication, database relationships, and business requirements - all while keeping the interface simple for users. While working on DKart, a B2B marketplace for medical and healthcare equipment, I had the opportunity to work on many of these challenges. In my previous article, I introduced DKart and its main features. In this article, I want to focus more on the technical side of building DKart, the technologies I used, the architecture decisions, and some of the challenges I faced during development. What Is DKart? DKart is a B2B marketplace for medical and healthcare equipment. The platform connects buyers and sellers so that businesses can discover equipment, create product listings, communicate with other businesses, negotiate requirements, and manage marketplace activities. The basic workflow is: Register → Verify → Discover → Communicate → Negotiate → Manage Instead of treating DKart as a simple product catalog, I designed it as a two-sided marketplace where buyers and sellers have different responsibilities and workflows. Choosing the Technology Stack One of the first decisions in any web application is choosing the right technology stack. For DKart, I wanted a stack that could provide: Fast frontend development Reusable UI components Responsive design Secure authentication Relational database support Easy development and deployment Scalable backend services The main technologies I used were: Frontend: React.js + Vite Styling: Vanilla CSS State Management: Zustand Backend Services: Supabase Database: PostgreSQL Authentication: Supabase Authentication Version Control: Git + GitHub Development Environment: VS Code Each technology had a specific role in the application. - Building the Frontend with React.js React was used to build the frontend of DKart. Since a marketplace contains many reusable elements, React's component-based architecture was useful for structuring the application. For example, different parts of the application could be organized into reusable components such as: Navigation bar Product cards Search interface Filter components Product details User dashboards Forms Authentication screens Seller listing interfaces Instead of creating every page independently, reusable components helped maintain consistency across the application. A product card, for example, can be reused in different areas such as the homepage, search results, category pages, and latest products. This makes the frontend easier to maintain as the application grows. - Using Vite for Development I used Vite as the development and build tool for the React application. One of the main reasons for choosing Vite was its fast development experience. During development, quick feedback is important. When making UI changes, I wanted the application to update quickly so I could test different layouts and interactions without unnecessary waiting. Vite also provides a straightforward setup for a modern React application. The development workflow became: Write Code → Run Development Server → Test UI → Make Changes → Repeat This made frontend development more efficient. - Managing State with Zustand A marketplace application has many pieces of information that need to be shared across different components. For example: Logged-in user information User role Selected filters Product information Marketplace state Application-level UI state For state management, I used Zustand. One reason I found Zustand useful was its relatively simple API and lightweight approach compared with more complex state-management solutions. Instead of passing data through many levels of components, shared state could be managed centrally where required. This helped keep the frontend structure cleaner. - Authentication and User Roles Authentication is especially important for a B2B marketplace. DKart needs to distinguish between different types of users and provide functionality according to their role. For authentication, I used Supabase Authentication. The general flow is: Register → Login → Authenticate → Identify Role → Load Appropriate Dashboard After authentication, users can access marketplace functionality according to their requirements. For example, a seller may need to: Add products Manage listings Respond to inquiries Communicate with buyers Manage business requests A buyer may need to: Search products Apply filters View product information Contact sellers Discuss requirements Submit requests This role-based approach was an important part of designing DKart. - PostgreSQL Database with Supabase For the database layer, DKart uses PostgreSQL through Supabase. A marketplace naturally contains relationships between different types of data. For example: User → Business → Product → Inquiry → Conversation → Request These relationships are easier to manage with a relational database. The database needs to represent information such as: Users Businesses Products Categories Product details Requests Conversations Marketplace activities Designing the database required thinking about how these entities would interact with each other. The goal was not just to store data but to structure it in a way that supports the marketplace workflow. - Designing the Product Listing System One of the core parts of DKart is the medical equipment listing system. Sellers need a way to publish equipment that buyers can discover. A listing can contain information such as: Product name Description Category Price Images Specifications Availability Seller information The listing system creates the foundation of the marketplace. A simplified flow looks like this: Seller → Create Listing → Add Product Details → Publish → Buyer Discovers Product This also required designing forms that are simple enough for sellers while still collecting useful product information. - Search and Filtering A marketplace becomes difficult to use if users cannot quickly find what they need. Medical equipment can belong to different categories and have different specifications, prices, and availability. Therefore, search and filtering were important parts of the frontend. The basic idea was: Search → Filter → Narrow Results → View Product → Contact Seller Instead of forcing users to manually browse through every listing, filters can help them reduce the number of relevant results. This also makes the marketplace experience more organized as the number of products increases. - Buyer-Seller Communication A major difference between a normal e-commerce website and a B2B marketplace is communication. In B2B transactions, buyers may have questions about: Product specifications Availability Pricing Quantity Delivery Custom requirements Because of this, DKart includes communication functionality between buyers and sellers. The idea is to keep the conversation connected to the marketplace instead of forcing users to depend entirely on external communication channels. This creates a more connected workflow: Discover Product → Contact Seller → Discuss Requirement → Negotiate - Negotiation in a B2B Marketplace Another important consideration was pricing. B2B transactions do not always follow a simple fixed-price model. Depending on the equipment, quantity, business requirements, and supplier, the final price may require discussion. Therefore, DKart was designed to support communication and negotiation between marketplace participants. The goal is to make the platform more aligned with real-world B2B procurement rather than treating every transaction like a standard online retail purchase. - Business Verification and KYC Trust is one of the biggest challenges in any marketplace. This becomes even more important when businesses are dealing with medical and healthcare equipment. DKart includes business verification and KYC-related functionality to help establish trust between participants. The overall concept is: Register → Submit Information → Verification → Participate in Marketplace The purpose is to create a more reliable environment where businesses can interact with greater confidence. - Dashboard-Based Marketplace Management Another important part of DKart is the dashboard. Instead of making users navigate through multiple disconnected pages, dashboards provide a centralized view of their marketplace activities. Depending on the user's role, the dashboard can include information related to: Products Listings Inquiries Conversations Requests Business activities This approach makes it easier for users to manage their work from one place. For a marketplace application, dashboards are especially useful because users can have multiple ongoing activities at the same time. - Challenges I Faced While Building DKart Building DKart was not only about writing frontend code. One of the biggest challenges was understanding how different marketplace workflows should work together. A buyer and seller may interact with the same product, but their actions and requirements are different. For example: Seller: Create Product → Manage Listing → Receive Inquiry → Communicate → Negotiate Buyer: Search Product → View Details → Contact Seller → Discuss Requirement → Negotiate Designing these workflows required thinking about both sides of the marketplace. Managing Application State Another challenge was deciding which information should be local to a component and which information needed to be shared across the application. Using Zustand helped simplify the management of shared state. It also encouraged me to think carefully about how data flows between components instead of simply passing information everywhere through props. Designing the Database The database was another important part of the project. A marketplace contains many connected entities. For example, one business can have multiple products, a product belongs to a seller, buyers can create inquiries,