In ProgressDjango 5Django REST FrameworkSimpleJWT

XigmaHardware — Hardware Commerce & Operations Platform

A specialized commerce platform for computer, server, workstation and datacenter hardware, combining catalog and inventory, stock-aware marketplace publishing, cart and wishlist, online payment, invoicing, location-aware logistics, accounting and realtime support.

Start Date: Views: 23
XigmaHardware — Hardware Commerce & Operations Platform

Project overview

XigmaHardware is more than a storefront. It is a hardware commerce operations platform designed for products whose technical identity, physical stock, online allocation, payment and delivery must remain consistent across several operational teams.

After 7 months of active development, the project stands at 75% completion. The technical foundation, catalog and inventory, marketplace, customer account, support and most operational dashboards are implemented. The remaining 25% is primarily production hardening: closing the full order-to-delivery loop, broader integration coverage, payment-provider resilience and final operational UX polish.

The business problem

Professional hardware retail is stock-sensitive and specification-heavy. A product may exist in multiple warehouses, some units may already be reserved, only a portion of physical stock may be allocated to online sales, and customers need brand, series, model, part number, condition and detailed technical specifications before purchasing.

On the operations side, a sale is incomplete without payment, invoices, shipment handling and customer support. XigmaHardware connects those domains so that physical stock, online visibility and actually sellable quantity do not drift apart.

Domain architecture

The backend is separated into clear domains: Accounts, Admin Panel, Stock, Market, Basket, Financial, Payment, Logistics, Support and Website. This separation is deliberate: Stock owns the technical and physical truth of a product, while Market owns the commercial page, SEO, media and sale-facing configuration.

Catalog-to-market publishing workflow

A product follows an explicit path before it becomes sellable:

Product → Warehouse → Inventory Item → Market allocation → Market Product

stock.Product owns SKU, identity, specifications, base pricing and market-allocation rules. InventoryItem connects the product to a warehouse and tracks quantity and reserved quantity. MarketProduct is the commercial layer with storefront copy, SEO, media, market pricing and order limits.

Free physical stock is calculated as:

available_quantity = quantity - reserved_quantity

Online availability is then capped by the quantity explicitly allocated to the marketplace. Increasing warehouse stock alone therefore does not accidentally publish inventory online.

Hardware-focused catalog

The stock model supports hierarchical categories, brands, series, model and part-number data, product condition, technical specifications, imagery and pricing. Development seed data covers datacenter, enterprise/office, home and workstation product families, making the catalog structure suitable for both B2C and professional hardware procurement.

Marketplace and buying experience

The Next.js 16 / React 19 frontend implements market browsing, product detail, reusable product cards, reviews, wishlist and cart flows. Out-of-stock products can remain published and retain their stable URL and SEO value while being clearly marked unavailable.

Customer identity and profile

The customer area supports individual and legal/company profiles, email/mobile verification, OTP flows, Persian date UX, address management, wallet transactions and invoice history. Authentication has also been hardened with single-session work so login behavior goes beyond simply issuing JWTs.

Role-aware backoffice

Operational roles include Super Admin, Accountant, Logistics, Courier, Stock Keeper, Helpdesk and Client. Navigation and dashboards are permission-aware so each team receives the tools relevant to its responsibility.

A custom Admin Panel API and /pannel-admin interface reduce dependence on Django Admin and provide a Persian operational UI while backend permission checks remain authoritative.

Finance and documents

The Financial domain includes accounting dashboards, transactions, invoices, document settings and PDF generation. Company identity, logo, stamp and signature can be incorporated into proforma/final invoice workflows and wallet-charge documents. Background tasks handle notifications and document delivery without blocking customer requests.

Online payments

Payment is abstracted from order/business logic and integrates ZarinPal and PayPing. ZarinPal supports sandbox/production behavior and separate verification. Final provider hardening, callback edge cases and production retry/failure paths are intentionally listed as remaining work rather than presented as finished.

Location-aware logistics

Neshan is used for reverse geocoding and coordinate validation. Delivery options include Tehran courier, Post, Tipax and Chapar. Shipment states cover pending, assignment, pickup, in-transit, delivery, return and cancellation, with dedicated logistics/courier workspaces.

Realtime support

Support combines structured ticketing with live chat, including guest chat before registration. Django Channels/WebSocket provides realtime communication while public-sensitive endpoints use throttling. Helpdesk therefore operates from a dedicated workflow rather than a basic contact form.

Media and infrastructure

Product images and video are handled through MinIO object storage. The repository defines separate Docker Compose environments for development, test, staging and production, with PostgreSQL, Redis, backend, Celery, storage, frontend and Nginx integrated into the deployment model.

Quality and DevOps foundation

The stabilization branch adds environment separation, CI, Pytest, frontend lint/build checks, security cleanup and targeted tests for authentication, single-session behavior, market APIs, stock-to-market management, Neshan logistics, accounting, invoice documents, payment verification and realtime support.

Engineering strengths

  • Catalog and marketplace separation prevents storefront concerns from corrupting stock truth.
  • Reserved stock + marketplace allocation avoids treating all physical inventory as immediately sellable.
  • Role-specific workspaces scale operational responsibilities across finance, logistics, stock and support.
  • Persian-first UX includes Jalali dates, localized validation, local delivery providers and pricing conventions.
  • Async/realtime separation uses Celery for background operations and Channels for live communication.

Business value

Business need XigmaHardware capability
Specification-heavy catalog Categories, brands, series, SKU, model, part number, specs
Avoid overselling Inventory, reserved quantity and market allocation
Multi-warehouse operations Warehouse + InventoryItem model
Controlled online publishing Explicit Product → MarketProduct workflow
B2C and B2B customers Individual/legal profiles and financial documents
Finance operations Wallet, transactions, invoices and PDFs
Iranian payments ZarinPal and PayPing gateway abstraction
Local/national delivery Neshan, Courier, Post, Tipax and Chapar
Customer care Ticketing, live chat and Helpdesk dashboard
Operational scaling Role-aware admin/accounting/logistics/support workspaces

Technology stack

Backend: Django 5, Django REST Framework, PostgreSQL 16, Redis 7, Celery, Channels, SimpleJWT

Frontend: Next.js 16, React 19, Emotion, React Hook Form, Jalali date UX

Infrastructure: Docker Compose, Nginx, Gunicorn, MinIO, GitHub Actions

Integrations: Neshan, ZarinPal, PayPing, SMTP/Email

Current status — 75%

The core platform, identity, catalog and stock, marketplace, wishlist, much of checkout, admin/accounting/logistics/support workspaces, Neshan integration, invoicing and realtime support are implemented.

Remaining 25%

The remaining work is mainly production-readiness:

  1. Close the complete Order → Payment → Verification → Invoice → Shipment → Delivery path with end-to-end tests.
  2. Harden payment provider callbacks, retries and real-world failure scenarios.
  3. Expand integration coverage between legacy domains.
  4. Finish operational CRUD/UX polish.
  5. Complete multi-channel notification and order/shipment edge cases.
  6. Add final observability and production acceptance testing.

The remaining work is therefore focused more on reliability and operational closure than on rebuilding the product architecture.

📸 Image Gallery

Catalog-to-fulfillment workflow
From Product and Warehouse to Inventory, Market, Basket, Payment and Shipment
1 / 2

Discussion & comments

Loading comments...