Admin panel
A complete tour of the admin: 50 pages, 4 roles, everything the owner and the team see.
TL;DR
The admin panel is the operational brain of the platform. About 50 pages, four access levels (Platform Admin, Store Admin, Manager, Dispatcher, Driver), three different layout contexts for the owner's desktop, the driver's mobile screen, and the dispatcher's mobile screen. Within a single system you have orders, catalog, inventory, promo mechanics (from bulk code generation to QR campaigns and Mix & Match), reports with daily financial reconciliation, customer wallets, review moderation, and fleet management — all living side by side. A separate layer is analytics: registration, login, and checkout funnels, an incident monitor, an activity log with user session recording, and an audit trail for catalog edits. The design is built around dark green #0e3814 as the primary color and dense table-driven interfaces with reusable components: StatCard, DataTable, status badges, modals. The goal of the section below is to show what the owner and the team can do with their own hands, without opening the database or calling the developer.
Context and roles
The platform handles delivery of regulated goods with age verification. This is not ordinary e-commerce: every order can include cash payment, a separate change-handling scenario for the driver, shift binding, delivery zone checks, ZIP-code restrictions during peak hours. That's why behind the single word "admin" there are several different workplaces.
Access is distributed via RoleGuard:
- Platform Admin — the only role with access to the Audit Trail. Sees absolutely everything.
- Store Admin — manages the store: catalog, inventory, promos, reports, wallets, settings.
- Manager — catalog, inventory, driver and vehicle fleet, review moderation.
- Dispatcher — mobile layout with the dispatch console, map, invoices.
- Driver — mobile layout with the driver dashboard, my orders, earnings.
The same URL can look completely different depending on the role. Routes that aren't accessible don't appear in the navigation, and trying to open them directly redirects to the role's allowed start page.
Owner's dashboard
Dashboard (/)
This is the command center for the owner. The first screen has two KPI tiers: lifetime (Collection, Sales, Orders, Users — all-time) and daily (the same metrics for today). Lifetime gives a sense of the business scale; daily is the pulse right now.
The central element is the Revenue Chart on Recharts BarChart with a date range picker, a toggle between Revenue and Orders, and a refresh button. Below it, a summary panel compares Lifetime and Today with TrendingUp/Down icons and a percentage delta, so the owner can immediately see whether the day was above or below average.
Separately — the "Users Sale" table: a list of customers with order count, revenue, profit/loss estimate per customer, and a Customer Since column. This isn't just KPIs anymore; it's a quick way to understand which customers are the core and which are one-offs.
Operations: orders, customers, fleet
Orders (/orders)
A page with all orders. At the top — OrderFilters with search, date range picker, status and driver filters, plus a download button for export. Then — Total Orders and Average Delivery Time counters, and a paginated OrdersTable. Each row is clickable and opens an OrderDetailModal.
Inside the modal the operator does three things: changes the order status through allowed transitions with a mandatory note, assigns a driver from a dropdown of available drivers, and updates the data. This is the key screen for the person on the phone with the customer.
Customers (/customers) and Customer Detail (/customers/:id)
A list of customers with search and a link to a personal card. The card collects contacts, order history, plan binding, wallet balance — everything an operations manager needs for a conversation with a specific person.
Drivers (/drivers) and Vehicles (/vehicles)
Fleet management, accessible from Manager role and up. Drivers — a list of couriers with their statuses and metrics. Vehicles — a vehicle registry: make, model, plate, driver assignment, documents.
Reviews (/reviews)
Moderation of product and order reviews. Manager and up can approve, hide, or delete a review before it lands in the public catalog.
Catalog
Catalog → Products (/catalog/products)
The main screen for the merchandiser. ProductFilters provides search, category and brand filters. ProductsTable displays products with edit, delete, and toggle visibility actions — the last one is especially important for regulated SKUs that need to be pulled quickly without deletion. ProductFormModal is the create/edit form with image uploads, category and brand assignment, price, cost, and inventory.
Catalog → Categories (/catalog/categories)
Category hierarchy. CRUD: create, edit, delete, reorder — for the business this is the catalog rubricator, for SEO it's the URL structure.
Catalog → Brands (/catalog/brands)
Brand registry with CRUD. Used in filtering, in product cards, and in banner logos. A separate entity, because one brand can cover dozens of products.
Inventory
Inventory (/inventory)
A standalone module with three tabs and a set of components: InventoryStats, InventoryFilters, InventoryTable, StockAdjustmentModal, LowStockAlerts, InventoryLogs.
The first tab — Inventory List. Filtering, stock adjustments via StockAdjustmentModal (with a reason), and a print button that opens inventory/print in a new window for physical reconciliation against the warehouse.
The second tab — Stock Alerts. Low-stock and out-of-stock items collected here with a badge counter directly on the tab icon, so the operator can see how many problems exist without opening the section.
The third tab — Activity Logs. A full paginated history of every adjustment: who, what, when, with what reason. This is one of the tools for internal control and discrepancy investigations.
Promotions
There's a whole separate domain in the platform — promo mechanics. There are five of them:
Promotions (/promotions)
Basic promo codes. Search by code, status filter, add and edit through PromoFormModal. CRUD operations: add, update, delete, toggle status. This is the root of all discounts.
Promo Code Batches (/promotions/promocodes)
Bulk generation of unique codes for campaigns and partnerships. Two views inside.
Batches View — a table of groups: name, discount type (% or $), usage progress, validity period, creation date.
Generate Modal — a powerful tool: you set the quantity (1–1000), prefix, code length (4–12 characters), discount type and value, minimum cart, maximum discount size, validity period. Separate checkboxes — "First Order Only" (the code only fires on a customer's first order) and "Cashback to Wallet" with a percentage, so the discount returns to the wallet rather than being deducted at order time. On the right side of the modal — a code preview, so you can see what a specific code will look like.
Codes View — inside the batch: search, status filter (Unused / Used), copy a single code, Copy All, and CSV export. The marketer generated a thousand codes for a campaign, exported the CSV, handed it to the partner — done.
Campaigns (/promotions/campaigns)
QR campaigns. At the top, four StatCards: Active Campaigns, Total Scans, Total Orders, Avg Conversion %. Below them — a table: name, code, QR button, linked promo code, scan count, order count, conversion percentage, revenue, and status (Active / Paused / Ended).
Create/Edit Modal lets you enter a code manually or generate one, specify the target URL, choose a linked promo code from a dropdown, enable auto-apply (the promo applies automatically on QR navigation), and set a validity period.
QR Modal renders a QR code via QRCodeCanvas; it can be downloaded as PNG. The tracking URL — {API}/api/v1/c/{campaignCode} — captures every scan and the link to the next order, so conversion is counted honestly.
Banners (/promotions/banners)
Storefront banner management. Table: thumbnail, title, type (Normal / Category / Promo), target device (Desktop / Mobile / All), sort order, active toggle.
The modal offers two upload paths for the image: drag-and-drop file (JPEG, PNG, WebP, AVIF, GIF, up to 10 MB) or an external image URL. Additionally — title, target URL, banner type, target device, category selector (if type=category is chosen), sort order, and status. A good example of how an operational screen closes a content task without a separate CMS.
Day-wise Discounts (/promotions/daywise)
Discounts per day of the week — one per day. Table: day, name, discount size (% or $), minimum cart, free gift information, cashback amount, status, edit and delete buttons.
The modal is split into thematic sections: Basic Info (day, name, description), Discount (type, value, minimum cart), Free Product (checkbox plus name and cart limit at which the gift is awarded), Wallet Cashback (amount and cart limit), Military Discount (checkbox plus percentage for a separate customer category), and Status. One screen — a whole weekly activation strategy.
Mix & Match (/promotions/mix-match)
The most complex promo tool: tiered discounts by quantity. Table: name + label, rule type, default discount, minimum quantity, number of tiers, status.
The modal is split into blocks: Basic Info (name, label, rule type — category_mix or product_bundle, description), Discount Settings (type, default value, minimum cart by amount and by quantity), Tiers (add and remove tiers — each with its own quantity threshold, value, and discount type), Scope (base category ID, list of applicable categories, and list of applicable products via UUID). This is how the business assembles mechanics like "buy 3 — get 10%, buy 5 — get 20%."
Reports: financials and operational reporting
The largest section in the admin. Everything the owner or accountant needs daily, weekly, and at the end of the month lives here.
Sales Report (/reports/sales)
Recharts BarChart "Sales Over Time" shows revenue by day, week, or month. Above the chart — period presets: Today, Yesterday, This Week, Last Week, This Month, Last Month, This Year, Custom. Group By sets the granularity.
KPI Cards come with period-over-period comparisons, with up and down arrows: Total Revenue, Total Orders, Average Order Value, Pending Orders. Below them — Secondary Stats: Discounts, Tax Collected, Delivery Fees, Tips, Cancelled count, Cancelled Value.
Tables complete the picture: Payment Methods (Cash, Zelle, CashApp, Venmo, Split — orders and amount per each), COD Collection Methods, Top Selling Products (rank, name, qty, revenue), Previous Period Comparison.
Reconciliation Report (/reports/reconciliation)
Financial reconciliation. This is no longer marketing — it's accounting. KPI Cards at the top: Gross Revenue, Net Revenue, Total Orders, Cost of Goods, Estimated Profit.
Financial Breakdown decomposes revenue: Gross, Discounts Applied, Wallet Used, Rewards Used, Net, Tax, Delivery Fees. The Payment Methods table shows the structure of payments.
Cash Flow — a separate block about cash: COD Sales Total, Cash in Envelope, Digital Payments (already on account), Change to Customer Wallets, Cash in Envelope (Net), Owner's Cash Total. This is critical because part of the money physically arrives in an envelope from the driver, and part goes to the customer's wallet as change.
P&L Summary — a dark green banner: Revenue, Tax, Delivery Fees, COGS, Estimated Profit. Below it — a collapsible Order Details section, where for each order: order #, date, customer, items, subtotal, discount, wallet used, cashback, total, payment method, cash received, change to wallet. When you need to understand why the day closed the way it did — this is the key screen.
EOD Report (/reports/eod)
End of Day — a report for one specific day, with CSV and PDF download. Metric Cards: Total Orders, ASAP Orders, Revenue, Collections, Avg Delivery Time, New Customers, Completed, Pending.
Cash Summary breaks the day down by payment method: COD Sales, Cash Envelope, Digital Payments, Change to Wallets, Owner's Cash, Card Sales, Crypto. A separate Products Sold table with image preview, quantity, category, and brand. Financial Summary closes the block with taxes, delivery, tips, and discounts. This report is sent to the owner every evening as a PDF.
Driver Report (/reports/driver)
Driver performance. Filters: date range, specific driver, region. Table: Driver Name, First Delivery, Last Delivery, # Deliveries, Avg Delivery Time, Sales, Cash Collected. At the bottom — a totals row. Salaries are paid and fleet expansion decisions are made based on this screen.
Cash Drop Report (/reports/cash-drop)
Cash reconciliation between driver and store at the end of the shift. At the top — the "Record Cash Drop" form: driver selector, period start and end, Calculate button.
After the calculation, the expected amounts appear: Envelope Orders, Expected Cash, To Wallets, Owner's Cash, and a separate callout about digital payments to make sure they can't be confused. Then — an Actual Amount field with live difference calculation (Difference), a Notes field, and a Record button.
Summary Cards: Total Expected, Total Dropped, Difference, Total Drops. The history at the bottom — a table of all drops: date, driver, expected, actual, difference (color-coded), order count, status (verified / disputed / pending). One of the most important financial controls in the system: this is exactly where shortages are caught.
Affiliate Report (/reports/affiliate)
Affiliate program. Filters: period, search by name / email / code. Summary Cards: Total Affiliates, Total Referrals, Total Revenue, Total Commission with the specified commission rate. A table broken down by affiliate with an Export CSV button.
COG Report (/individual/cog)
Cost of Goods, accessible from Store Admin role and up. KPIs: Revenue, Cost of Goods, Gross Profit, Gross Margin %, Inventory at Cost. If some products have no cost, a warning banner sits at the top. Product Breakdown shows for each SKU: name, qty sold, revenue, cost, profit (green for positive, red for negative), margin % with the same color coding. This is one of the most useful analytical screens for the product manager: it immediately shows which products make money and which just shuffle stock.
Invoices (/reports/invoices)
Invoices per order. Filters: date range, New Registration / Min Qty / Next Day Only checkboxes, CSV download button. Table: date, time slot, phone, user, email, store, driver, status, creation date, grand total, view button.
Invoice Detail Modal — a standalone artifact. Shipping label preview in 80×80 mm format, Print Label button, and PDF download via jsPDF + autoTable. The PDF includes: store details, order details, customer information, driver, an itemized list, and a breakdown of all totals. Effectively, it's a full document for printing and accounting.
Daily Orders (/reports/daily-orders)
Orders by shift. There's a nuance here: the shift starts at 06:00 Miami time, and the report respects that offset, so the data isn't broken across the calendar midnight.
Wallet History (/reports/wallet-history)
History of customer wallet operations in the report context (rather than per individual user).
Settings
Settings → Store (/settings)
Four tabs:
- Store — overall store configuration: name, contacts, details, settings.
- Time Slots — add, edit, delete delivery slots and an active toggle for each.
- Delivery Zones — CRUD for zones where delivery operates (with rules by amount and time).
- Traffic Windows — ZIP restrictions for peak hours: during rush hour, some zones can be turned off, and the storefront sees that.
Roles (/settings/roles)
RBAC role management. Table: name, description, brief permission summary, type (System / Custom), status, edit and delete buttons (system roles cannot be deleted). Permission assignment is done at the module level. This gives the owner the flexibility to add a new role for an accountant or warehouse worker without hiring a developer.
Employees (/settings/employees)
Employee list: name with avatar, email, phone, role, status (Active / Inactive plus a separate Online indicator), last login, edit, delete. The modal lets you assign a role and change details.
Customer Plans (/settings/plans)
Configuration of customer premium tiers. Each plan is a separate card with a colored header: Name, color picker, Cashback %, minimum order amount.
Inside the card — payment method checkboxes (COD, Crypto, Wallet) and cash collection methods (Cash, Zelle, CashApp, Venmo). Then — support hours, delivery hours, delivery window start/end. A bonus product picker with slug search, a bonus description, and a description for the storefront.
Separate toggles: show the plan only after the first order, allow 24/7 orders bypassing store hours, allow orders bypassing ZIP restrictions. This is a retention tool: customers with a premium plan can be granted windows that are off-limits to everyone else.
Wallets
Wallet List (/wallet)
Search by email, table: email, balance, creation date, view button. At the top — a Money Transfer button that opens MoneyTransferModal for transfers between wallets. And a Download button — CSV export of all balances.
Wallet Details (/wallet/details/:userId)
User card with balance and an Add Balance button. Below it — a table of all transactions: email, amount (color-coded, plus in green, minus in red), to whom, order ID, reason, comment, date.
Wallet Logs (/wallet/logs)
Global log across all wallets. Search by email, phone, reason. Table: who transferred, to whom, amount, reason (Credit / Debit / Refund / Bonus / Order Payment / Cashback), creation date, view (link to the user's detail page). This is one of the main anti-fraud tools: suspicious credits are visible immediately.
Analytics
Conversion Analytics (/analytics/conversion)
The funnel: Sessions → Product Views → Cart Adds → Checkout → Orders, with a transition percentage at each step. Below the funnel — a Recharts LineChart with three series: Sessions (dark green), Orders (red), Cart Adds (yellow, dashed). This is the first page a marketer opens in the morning.
Activity Log (/activity-log)
Client-side tracking with four tabs.
All Events — filter by event type (page_view, product_view, cart_add, cart_remove, checkout_start, checkout_success, api_error, js_error, and so on), by user ID, by session ID. Table: time, event badge (color-coded), user, URL, session (clickable, leads to User Journey), IP. Each row is expandable: it shows the raw JSON payload of the event.
Errors — grouped errors: message, type, source, repeat count, first/last seen. This is the first diagnostic point when something goes wrong on the site.
Search Analytics — Top Searches and Searches with No Results. Visible: what users search for and where the site fails them.
User Journey — entering a session ID triggers loading of the entire session path: numbered steps, badges, timestamps, URLs, payloads. The Watch Replay button opens rrweb-player via dynamic import and plays back the actual recording click-by-click.
Audit Trail (/audit-trail)
Platform Admin only. This is a different level of control — not the customer, but internal users.
Summary Cards: Product Changes Today, Product Changes (7d), Wallet Ops Today, Top Modifier (7d) — which admin made the most edits over the past week.
Product Changes is shown as grouped cards: changes made by one user within two seconds collapse into a single block. Each card shows an action badge (Created / Updated / Deleted / Variant Added / Updated / Deleted), timestamp, performed by, and product name. Smart change display puts priority fields first: name, price, sale price, cost, inventory, active, featured, category, brand. The remaining edits are hidden under an expandable "+N more." Formatting context — prices are shown as $, booleans as Yes/No, category and brand IDs are resolved into human-readable names, long text is truncated. Variant changes are separate indented sub-items.
Wallet Operations — a table: time, admin name, customer name, type badge (credit / bonus / refund / debit), amount, balance before and after, reason. This is the final tool against internal fraud: the owner sees every cent credited by an admin.
Issues Monitor (/analytics/issues)
Incident cards: Checkout Failures (with a top of causes) and JS Errors (with a top of messages). Period presets: Today, Yesterday, 7d, 30d. This is a short morning briefing for the product manager: where today hurts.
Registration Funnel (/registration-funnel)
OTP-based registration funnel. Stages: sent (code sent), registered (user created), verified (code confirmed), abandoned. Plus — conversions between stages and timing (how long passes between steps). Visible: at which stage customers are lost.
Login Funnel (/login-funnel)
The same, but for login: how many users make it to a successful login and where they drop off.
Checkout Funnel (/checkout-funnel)
Checkout funnel: from start to a successful order, with drop-offs and reasons highlighted.
Storefront content
Homepage Manager (/homepage)
Accessible from Store Admin role. Manages featured products: up to 8 slots on the homepage. Product search, category filter, slot arrangement. No separate CMS, no developers — this is the marketer's daily work.
Help (/help)
Help section for all roles: how to use the sections, common scenarios, answers to frequent questions.
Driver Layout
When a driver logs in, they see a completely different interface — mobile, designed for one hand, with large elements.
Driver Dashboard (/driver-dashboard)
Welcome header with name and today's date. The main element is the Online/Offline toggle: a large green pulsing button that requests geolocation on tap and puts the driver on shift. Below it — an alert banner with pending orders, widgets for shift status, active orders, earnings. Down — links to My Orders.
My Orders (/my-orders) and My Orders Detail (/my-orders/:id)
A list of assigned orders. Tapping an order opens the detail page with the route, customer contact, contents, payment method, and status transition buttons: Pickup, On the way, Delivered.
Dispatcher Layout
The dispatcher also sees a mobile interface, but for a different task.
Dispatcher Console (/dispatcher)
The dispatcher's main screen. DispatcherStats shows shift overview metrics. PendingOrdersList — orders awaiting assignment, with a status filter. DriversList — all available drivers with an online indicator and the number of active orders in progress. AssignOrderModal — assign an order to a specific driver. A separate DispatcherCustomers block gives quick access to customer information. Auto-refresh runs through React Query invalidation: data updates by itself, no F5.
Dispatch Map (/dispatcher/map)
Geographic dispatch view. The map shows drivers and orders geographically, so the dispatcher can see who to assign to an order based on position, not just the name in the list.
Dispatcher Invoices (/dispatcher/invoices)
The same invoice module as in the main admin, but launched in dispatcher layout — mobile, convenient for working from a phone.
Telegram mini-apps
Beyond the main web admin and storefront, the platform has three separate Telegram mini-apps: a customer store, a dispatcher app, and a driver app. These are standalone SPA applications on Vite + React that launch inside Telegram via the WebApp API: the user installs nothing and registers separately for nothing — the mini-app opens directly from the chat with the bot and immediately recognizes the person via Telegram.WebApp.initData. The initData signature is verified on the server via HMAC, and on first entry into the system a minimal profile is created (phone in the format tg_{telegram_id}, name from Telegram). From there, the customer, dispatcher, and driver have three completely different experiences on a single backend codebase.
Sales mini-app — store in Telegram
An anonymous catalog, opened via a short domain through the bot. Before entry — an age verification gate (21+) to comply with the platform's and regulators' requirements. After the gate, the full catalog appears: a horizontal list of categories, a Featured section with carousel product cards, a grid with prices and potency, a cart icon in the header.
The cart lives in localStorage — no server sync, so the order can be assembled without authorization. Only at checkout time, through Telegram, does binding to the customer profile appear: the same checkout as on the storefront, with all scenarios (Express, Scheduled, Cash, Wallet), but in a dense mobile layout tailored for one hand.
A separate flow in this mini-app is the Affiliate Program: the customer can become a partner, receive a personal promo code and a share link, which they share with friends right inside Telegram. From there, notifications about a new order, its confirmation, and delivery statuses arrive in the customer's chat with the bot — without push notifications and without email.
Dispatcher mini-app — dispatch in your pocket
Launches from a chat with the dispatcher bot. Authorization — through Telegram, the binding to the dispatcher role is done automatically by telegram_id, which is pre-mapped in the admin. After login, the dispatch console opens: a KPI strip on top (Pending, Ready, Assigned, Delivery, Drivers, Done), four tabs — Orders, Drivers, Customers, Map.
In the Orders tab the dispatcher sees active orders as a list: number, amount, delivery type (EXPRESS / scheduled time slot), date, customer name, address, and distance from the warehouse. On tap — a detailed order card with the option to assign a driver from the list of free ones. By default, the list is filtered by Area — the dispatcher can limit themselves to their zone of responsibility.
In the Drivers tab — a list of all drivers with an online/offline indicator, active vehicle, delivery count. Free drivers are highlighted green, busy ones gray. You can tap a driver and see their recent deliveries.
The Customers tab — quick access to customers: search by name or phone, an Add Customer button for manually creating a profile when an order comes in by phone, each entry shows all-time order amount and contact.
And finally, Map — geographic visualization: a map of the delivery zone (the Miami area and its suburbs) with markers for drivers and order points. Centering and zoom — over Leaflet, tiles — through OpenStreetMap. This is, possibly, the most-used tab of an active dispatcher: they see who among the drivers is closer to a new order, and assign in a couple of taps.
All data is updated through a WebSocket channel: a new order — arrives in real time, a change in driver or order status — also. Push notifications via Pushover duplicate critical events (new order → priority=2, at maximum volume) so the dispatcher hears them even when the phone is in their pocket.
Driver mini-app — driver in Telegram
Launches from a chat with the driver bot. The driver's Telegram account is bound to their profile in the system through preassigned mapping — the driver enters no passwords. After login, the dashboard opens.
On the main screen — the driver's card with name and current shift status (Offline / Online), a vehicle selector from the list of assigned ones, the main green Go Online button. On tap, geolocation is requested, and the driver enters active mode: their coordinates start being transmitted to the server every N seconds, and their avatar becomes visible on the dispatcher's map.
The Orders tab — a list of orders assigned to the specific driver. Each has a status (Assigned, Picked Up, On the way, Delivered), transition buttons, and built-in navigation links: "open in Google Maps" or "call the customer." On order completion — a modal confirming the cash amount (if COD) and a photo for proof-of-delivery.
The Earnings tab — the driver's earnings: today, week, month. Shown: base rate, tips separately, and total deliveries. This closes the classic gig-economy driver pain: "how much have I earned by now and is it worth working another hour."
Under the hood, all three mini-apps share a common API (NestJS) with the web storefront, common customer and order entities, a common notifications queue (Redis pub/sub), a common WebSocket event format. Only the UI and the set of endpoints accessible to each role differ. This lets an order created in the Sales mini-app appear on the dispatcher's map within seconds, and after assignment — in the driver's mini-app within the next seconds. All inside a single Telegram ecosystem, without switching between apps.
Login
Login (/login)
Entry point to the admin. Protected by GuestGuard: an already authenticated user is redirected to their start page, depending on role.
Design patterns and a unified interface language
To keep 50 pages with different functionality from turning into a zoo, a common language is maintained across the admin:
- Color. Dark green #0e3814 — primary for headers, buttons, sidebar. Dark panels in this color with white text are used in summary blocks and chart sections, to visually separate "totals" from working tables.
- StatCard. A universal component for KPIs. Used in Dashboard, Sales Report, EOD, Campaigns, Activity Log, and others — everywhere with the same layout: icon, number, caption, optional arrow with percentage delta.
- DataTable. A reusable component with dark variant support. All lists — orders, products, banners, wallets, reviews — are built on top of it, so pagination, hover effect, and column alignment behave the same everywhere.
- Status badges. A semantic color scheme: green for active and delivered, yellow for pending, red for cancelled, blue for confirmed. Reads instantly, no need to dig into a legend.
- Modal pattern. Everywhere the same fixed overlay with close on backdrop click. No surprising "this other modal works differently."
- Toggle switches for statuses (visible / hidden, active / inactive) — more compact than buttons, and they give immediate feedback.
- Pagination through Previous / Next, without fragmentation into smaller approaches.
- Loading state — Loader2 from lucide-react with the same animation everywhere.
- Icons — exclusively lucide-react, no mixing with other sets. This matters both for visual integrity and for bundle size.
Together, this gives the feeling that 50 pages are one product, not five different ones taped together.
What this means for the business
Most external e-commerce admin panels cover the first two or three layers: catalog, orders, users. Here, we tried to go noticeably deeper: daily financial reconciliation, control of the driver's envelope cash, an audit trail of catalog and wallet edits, separate funnel analytics for registration, login, and checkout, recording of user sessions with replay inside the admin, multi-role with mobile layouts for driver and dispatcher.
From an operations perspective, this means the owner and the team can run the business on their own, without going to the developer for routine tasks. From a product perspective — that the system has built-in tools for self-diagnosis: where the money is leaking, where conversion is dropping, which admin is changing things at night, which SKUs aren't earning margin.