Overview
Emisell Merchant Dashboard is the central control panel for merchants on the Emisell platform. I joined this project mid-development — inheriting an existing codebase, resolving bugs, and contributing new features on top of what was already built. It covers a wide range of features: sales analytics, order and draft management, product catalog, customer management, discount configuration, content management, and deep store settings including checkout, shipping & delivery, and location management.
Problem
Managing an online store requires juggling many concerns at once — from tracking sales performance to configuring shipping rules and handling customer data. A poorly structured dashboard makes this overwhelming. Emisell Merchant Dashboard was built to give merchants a single, well-organized hub to operate their entire store efficiently.
Key Features
- Analytics — gross sales, average order value, orders over time, and returns, all filterable by date range
- Order Management — full order list and draft orders
- Product & Customer Management — product catalog, variants, and customer data
- Discounts — discount rule configuration
- Content & Settings — content management alongside extensive settings covering checkout flow, shipping & delivery, store locations, and more
Technical Highlights
Dynamic address schema per country was one of the more nuanced challenges — different countries have different address field requirements (states, provinces, postal code formats, etc.), so the form schema had to be dynamic and driven by the selected country, not hardcoded.
Feature-based architecture was key to keeping the codebase manageable at this scale. Components
were split into two layers: compose (feature-specific components tied to a particular page or
domain) and shared (reusable components across features). This separation kept each feature
self-contained and prevented the codebase from becoming a tangled mess as the project grew.
Server state synchronization was handled with a mix of SWR (carried over from the existing codebase) and TanStack Query for newer features. Both tools were used where appropriate — SWR for simpler data fetching patterns already in place, TanStack Query for mutation-heavy flows that needed fine-grained cache invalidation across interconnected features.