Nepal Denims
A production e-commerce and operations platform I designed and built for Nepal Denims, a Kathmandu-based children's fashion business. The project combines a customer-facing storefront, a full administrative back office, content management, order processing, inventory operations, security controls, monitoring, and production infrastructure in one Next.js application.
Overview
Purpose: I built Nepal Denims to give the business a complete digital commerce platform instead of relying primarily on manual or social-media-driven selling processes.
Target users: Retail customers browsing and purchasing children's clothing; wholesale and bulk-order buyers; internal staff managing products, orders, inventory, content, customers, returns, promotions, and operations.
- Production storefront with category browsing, product variants, cart, wishlist, search, product comparison, quick view, checkout, and account flows
- Bulk-order and inquiry workflows designed for Nepal Denims' wholesale-oriented business model
- Administrative platform for commerce, inventory, CMS, customers, marketing, permissions, monitoring, and operational workflows
- Nepal-specific payment and delivery support
- Centralized inventory architecture covering reservations, physical stock movement, production, transfers, adjustments, and returns
- Production-grade SEO, security, observability, validation, and deployment practices
Tech Stack
Confirmed directly from package.json, prisma/schema.prisma, and docs/architecture-decisions.md in the private repo (Himesh-Bhattarai/anshu-ecommerce). Note the repo has since rebranded from "Anshu Baby Fashion" to "Nepal Denims" mid-project — docs explicitly say not to use the old name in new copy, and the live domain nepaldenim.com (singular, matching the résumé) now 308-redirects to nepaldenims.com (plural).
Frontend
- Next.js 16 — App Router and Server Components
- React 19
- TypeScript
- Design-token-driven CSS architecture
- Zustand for client-side state
- BroadcastChannel for cross-tab state synchronization
- shadcn / Base UI primitives for administrative interfaces
- React Markdown + remark-gfm for CMS content rendering
Backend
- Next.js Server Actions
- Next.js Route Handlers
- Zod validation at server boundaries
- Centralized domain services for inventory, orders, returns, authentication, monitoring, email, storage, and support
Database
- PostgreSQL on Neon
- Prisma ORM 7
- Separate production and development database branches
- Transactional writes for stock-sensitive and money-sensitive operations
Auth
- Auth.js v5
- Credentials authentication with bcrypt
- Google OAuth
- JWT-based sessions
- ADMIN, STAFF, and CUSTOMER role model
- StaffPermission-based module authorization with secure-by-default access
DevOps
- Vercel
- GitHub Actions
- Vercel Blob
- Vercel Web Analytics
- Vercel Speed Insights
- Sentry
- UptimeRobot
- Resend + React Email
Features
Storefront Catalog & Product Discovery
I built a server-rendered storefront with category browsing, product detail pages, size and color variants, product imagery, quick view, wishlist, cart, comparison and bulk-order actions.
How: Product and category content is rendered server-side for crawlability and fast first response. Interactive controls remain isolated client components. Product variants remain synchronized with price, stock, size, and color availability.
Benefit: Customers can discover products quickly while Nepal Denims retains structured catalog control through the admin panel.
Checkout & Payments
Checkout is designed around server-authoritative pricing and inventory correctness.
How: Server recomputes order totals from current product and variant data. Client-submitted prices are never treated as authoritative. Order creation and stock operations are coordinated transactionally. Cash on Delivery is supported for the local market. eSewa and Khalti payment flows are integrated into the payment architecture. Payment status and order status are modeled independently for operational clarity.
Benefit: The checkout process protects against stale pricing, invalid totals, and stock inconsistencies while supporting payment methods relevant to Nepal.
Bulk Ordering
Nepal Denims serves wholesale and larger-volume buyers, so bulk ordering is treated as a dedicated workflow rather than a normal cart with larger quantities.
How: BulkInquiry and BulkInquiryItem model the pre-order commercial discussion. Inquiry creation does not incorrectly consume inventory. Confirmed conversion into an Order enters the same order and inventory domain as normal commerce.
Benefit: Wholesale customers can engage with the business without forcing retail checkout assumptions onto large orders.
Admin Panel
I built a full back-office environment under /admin for daily store operations: Dashboard, Orders, Bulk Orders, Products, Categories, Brands, Inventory, Customers, Reviews, Promotions, Coupons, Flash Sales, Campaigns, Email Campaigns, Push Notifications, CMS content, Team Members, Roles & Permissions, Activity Logs, Settings, System Health.
How: Every privileged mutation is validated server-side and protected independently from the UI.
Benefit: Non-technical staff can operate the business from one system instead of depending on the developer for routine updates.
Inventory Management
I designed the inventory system as a centralized domain rather than allowing individual pages or order flows to mutate stock independently. Core concepts: InventoryBalance, InventoryReservation, StockMovement, Location, ProductionBatch, StockTransfer, StockAdjustment, StockCount.
How: Core operations: Reserve, Release, Consume, Receive production, Transfer stock, Adjust stock, Reconcile counts, Return/restock. Web, manual, and converted bulk orders use the same inventory domain. Order creation reserves inventory; cancellation releases reservations. Concurrency-sensitive writes are handled transactionally.
Benefit: Inventory behavior is consistent regardless of where an order originates, reducing overselling, duplicated stock logic, and reconciliation problems.
Production, Transfers & Adjustments
The inventory module supports more than storefront stock: production batch tracking, stock transfers between warehouses/factories/outlets/online locations, and controlled stock adjustments/count reconciliation.
How: Preserves batch-level and movement-level operational history for auditability.
Returns & Support
I implemented structured return and support workflows instead of treating returns as arbitrary stock edits. Return lifecycle: Requested → Approved → Received → Restocked / Refunded.
How: Return handling is connected to order state and inventory behavior. SupportTicket and TicketMessage provide a structured customer-support trail.
Cross-Tab Cart Synchronization
Cart changes remain synchronized across multiple open browser tabs.
How: Zustand maintains the active client state; BroadcastChannel distributes the authoritative post-mutation cart state; receiving tabs hydrate directly from the updated payload, avoiding unnecessary duplicate server round trips.
Benefit: I eliminated stale-cart behavior while keeping synchronization lightweight.
Authentication & Staff Permissions
The application supports customer accounts and administrative access with clear authorization boundaries.
How: Credentials + OAuth authentication, JWT sessions, bcrypt password hashing. ADMIN has full administrative capability; STAFF receives explicitly granted module permissions; missing StaffPermission rows mean access is denied. Protected actions revalidate the authenticated session server-side.
System Health
I created an internal operational dashboard that brings multiple infrastructure signals into one admin view: PostgreSQL reachability/latency, Sentry issue visibility, UptimeRobot endpoint status, Vercel analytics, storefront/admin/checkout/auth endpoint visibility.
How: External monitoring integrations fail safely so a third-party monitoring outage does not break the admin system itself.
Transactional Email
Resend + React Email power transactional communication: order confirmations, order status updates, password resets, stock alerts, team invitations, bulk inquiry notifications.
SEO Infrastructure
SEO is part of the application architecture rather than an afterthought.
How: generateMetadata, Open Graph metadata, Twitter cards, Product/BreadcrumbList/Organization JSON-LD, dynamic sitemap, robots configuration, human-readable product slugs, noindex rules for private/account/checkout surfaces, server-rendered indexable content.
Architecture
Folder structure: src/app/(storefront) · src/app/(auth) · src/app/(admin)/admin · src/app/api · src/components/ui · src/components/admin · src/components/product · src/components/cart · src/components/wishlist · src/lib/auth · src/lib/inventory · src/lib/returns · src/lib/monitoring · src/lib/seo · src/lib/email · src/lib/validation · src/lib/store — the application intentionally keeps UI, domain behavior, persistence, and infrastructure concerns separated.
App flow: Commerce lifecycle: Customer selection → server-side validation → server-side price calculation → inventory reservation → order creation → payment/order status lifecycle → fulfillment → inventory consumption → transactional communication.
Auth flow: Admin lifecycle: Admin request → authenticated server-side session validation → permission validation → domain mutation → database transaction → audit/activity record → UI refresh / notification.
Database Design
- Commerce — Product, ProductVariant, ProductImage, Order, OrderItem, Payment, Cart, CartItem, Wishlist, WishlistItem, BulkInquiry, BulkInquiryItem
- Inventory — InventoryBalance, InventoryReservation, StockMovement, Location, ProductionBatch, StockTransfer, StockAdjustment, StockCount
- Customer Operations — Return, ReturnItem, SupportTicket, TicketMessage
- Administration & Security — StaffPermission, AuditLog, RateLimitBucket
- CMS & Merchandising — CmsPage, HeroSlide, SiteSettings, Category, CategoryShowcaseItem, Brand, SizeChart, SizeChartRow, SizeOption, ColorOption
Money uses Decimal rather than floating-point values, and order shipping information is snapshotted so historical orders are not changed when a customer later edits an address.
API Documentation
The project primarily uses Server Actions for first-party application mutations and Route Handlers where HTTP interfaces are appropriate. Key server interfaces cover authentication, account operations, checkout, orders, bulk inquiries, inventory, returns, support, admin mutations, health checks, monitoring, and CMS operations. External input is validated at server boundaries; business rules live in reusable domain logic instead of being duplicated in UI components.
Authentication Flow
login: Customer/admin login: credentials or OAuth → Auth.js validation → JWT session → httpOnly cookie → server-side authorization.
middleware: Administrative request: request → requireAdminSession() → role/StaffPermission validation → action execution.
notes: Security decisions are always enforced on the server; hiding a button in the UI is never treated as authorization.
Screenshots
Challenges
Problem: Multi-Tab Cart Consistency — multiple tabs could hold independent local cart snapshots.
Solution: I introduced BroadcastChannel synchronization using the authoritative cart payload returned after a successful server mutation.
Lessons: Cart state updates across tabs without an unnecessary second server fetch.
Problem: Authorization Hardening — fine-grained mutations require both authentication and ownership/authorization validation.
Solution: I audited privileged actions systematically and strengthened identity scoping on sensitive operations.
Lessons: Authorization is enforced at the mutation boundary instead of relying on navigation or UI state.
Problem: Inventory Concurrency — multiple simultaneous orders must not oversell limited inventory.
Solution: I centralized inventory mutations, defined explicit inventory invariants, and implemented transaction-safe reservation and movement behavior.
Lessons: Retail, manual, bulk, production, transfer, return, and adjustment flows follow one stock model.
Problem: Operational Monitoring — infrastructure status was distributed across multiple vendor dashboards.
Solution: I consolidated database, error, uptime, and analytics signals into the System Health admin surface.
Lessons: Operational issues can be checked from one internal interface.
Performance
- Server Components by default
- Client JavaScript restricted to interactive leaves
- next/image responsive delivery
- Vercel Blob-backed media
- Reduced font payload
- Tuned image quality
- Indexed high-frequency database query columns
- Server-side rendering for crawlable content
- Vercel Speed Insights for production visibility
Security
- Server-authoritative order totals
- Transactional inventory and order writes
- bcrypt password hashing
- JWT sessions in httpOnly cookies
- Server-side admin authorization
- Zod validation
- Database-backed login rate limiting
- Decimal money fields
- Security headers
- Secure handling of payment redirects
- Sentry monitoring
- Dependency auditing
- Environment-separated development and production databases
Deployment
hosting: Vercel
cicd: GitHub Actions — validates dependency installation, linting, generated Next.js types, TypeScript correctness, tests, and commit/PR conventions. Vercel preview deployments provide an additional production-style build gate.
prodSetup: Database: Neon PostgreSQL · Storage: Vercel Blob · Email: Resend · Monitoring: Sentry + UptimeRobot + Vercel Analytics
Future Improvements
- Richer wholesale workflows
- Deeper inventory analytics
- Location-scoped operational permissions
- Additional payment automation
- Expanded merchandising and campaign tooling
- Continued performance/security hardening
Lessons Learned
- Domain rules become easier to test and maintain when stock behavior is centralized instead of scattered across order screens.
- Server-side authority is essential for money, inventory, permissions, and other correctness-critical operations.
- Operational tooling should be part of the product, not only external dashboards known to the developer.
- Root-cause debugging is more valuable than applying the first obvious fix.
- Numbered invariants and explicit lifecycle rules make complex operational systems easier to review and extend.
- A maintainable admin system is a product in its own right, not a secondary collection of CRUD screens.
Project Metrics
Timeline
- August 2026 — Core application structure, database, storefront, authentication, and deployment established
- August 2026 — Security, rate limiting, cross-tab synchronization, and admin hardening
- August 2026 — Inventory architecture and operational workflows implemented and aligned across ordering channels
- August 2026 onward — Production hardening, performance optimization, CMS expansion, monitoring, and business-operation improvements
Ask about this project
Depends on the /api/chat orchestrator and MCP tool server — not built yet (see plan.md).
Recruiter Summary
Role: Solo Freelance Full-Stack Developer
- Translated client requirements into a production commerce and operations platform
- Designed the storefront, administrative system, database model, authentication, and inventory architecture
- Implemented full-stack features across commerce, inventory, CMS, returns, customer operations, security, and monitoring
- Built production deployment and CI workflows
- Designed server-authoritative business rules for money, permissions, and stock
- Maintained the application through systematic testing, auditing, debugging, and performance work
- Delivered a real production e-commerce platform used by a client business
- Replaced fragmented operational workflows with a centralized administrative environment
- Built a unified inventory model supporting retail, wholesale, production, transfers, adjustments, and returns
- Reduced operational dependence on the developer by giving staff direct control of store functions
- Established a secure, observable, maintainable foundation for continued business growth