Gritnox — Case Study — Zisanur Haque

01 / The context

The problem worth solving.

Industrial procurement often begins with incomplete part numbers, equipment models, manufacturer references, or supplier-specific identifiers. Similarity-based search alone cannot establish component compatibility, while combining part identity, fitment evidence, and supplier pricing can produce misleading purchasing decisions. Beyond discovery, a multi-vendor marketplace must enforce account permissions, seller ownership, order transitions, and administrative controls consistently across its API and interface.

The product

Developed Gritnox as a full-stack industrial parts discovery and procurement platform. A Next.js interface communicates with a Django REST API backed by MongoDB. The domain model separates canonical part records, identifiers, equipment fitment evidence, and supplier offers. Authenticated workflows use server-enforced authorization and session-based security, while buyer, seller, and administrator workspaces demonstrate marketplace operations. Explicit data disclosures and a controlled demo environment distinguish implemented workflows from live commercial capabilities.

02 / My contribution

Where I was involved.

Independent product concept development, product architecture, full-stack engineering, domain modeling, and interface design. Responsible for shaping the industrial procurement experience, structuring the catalog and fitment model, implementing frontend and API workflows, developing session and authorization boundaries, and documenting implementation status and operational constraints.

03 / System approach

How the pieces fit.

The system separates the Next.js App Router frontend, Django REST API, and MongoDB persistence layer. The frontend renders public discovery, sourcing, documentation, and role-specific dashboard experiences. The API owns request validation, authentication, authorization, and marketplace workflow rules, while MongoDB stores catalog records and application workflow data. Public catalog reads remain independent of checkout. Authenticated state-changing requests use session-based authentication and CSRF protection. A disclosure layer communicates fitment evidence, illustrative catalog data, demo restrictions, and production-validation requirements.

Next.js
TypeScript
Python
Django
Django REST Framework
MongoDB
Stripe

04 / Engineering details

Inside the implementation.

01Separating Part Identity from Compatibility Evidence

Requirement: A valid catalog record does not prove that a component fits a particular machine. Likewise, a plausible fitment claim does not guarantee that a supplier offer is current or commercially suitable.
Implementation: Separated catalog parts, identifiers, equipment fitment records, cross-references, and supplier offers into distinct data responsibilities. Fitment records retain explicit evidence states, relationship types, and review context, while offers preserve their own commercial attributes and freshness.
Result: Established a discovery and comparison model that distinguishes component identity, compatibility evidence, and commercial availability rather than collapsing them into a single trust indicator.

02Enforcing Marketplace Authorization at the API Boundary

Requirement: Client-side navigation guards cannot protect sensitive API operations. Multi-vendor workflows also require controls against role escalation, seller self-approval, cross-vendor changes, and unauthorized order or payout transitions.
Implementation: Implemented HttpOnly session-cookie authentication, CSRF-protected writes, session revocation, login throttling, and server-side role and ownership checks. Administrative store activation, order transitions, and withdrawal workflows use explicit authorization controls.
Result: Made authentication and authorization part of the backend contract rather than relying on interface visibility. The project documents its implemented controls and outstanding production-review requirements without claiming external security certification.

03Maintaining Financial and Operational Consistency

Requirement: Marketplace metrics can become misleading when unsettled transactions are counted as sales or amounts in different currencies are combined into a single total.
Implementation: Defined seller analytics around paid order activity and used currency-separated trends. Administrative rankings use fulfilled units instead of summing incompatible monetary values. The catalog also preserves currency as a distinct supplier-offer attribute.
Result: Established clearer accounting boundaries for marketplace reporting and more meaningful comparisons across orders, suppliers, and currencies.

04Building a Reviewable Multi-Role Demonstration

Requirement: Static screenshots cannot demonstrate connected workflows, and unrestricted demo credentials can introduce unnecessary security and operational risks.
Implementation: Implemented a gated demo entry mechanism that resolves predefined role keys to fixed server-configured identities. Dedicated fixtures and scoped reset behavior support buyer, seller, and administrator walkthroughs without exposing production credentials.
Result: Created a repeatable evaluation path through role-specific marketplace workflows, with explicit boundaries around illustrative records and non-commercial demo activity.

05Hardening the Application for Deployment

Requirement: A successful page render or frontend build does not establish that database migrations, backend integration, security controls, and end-to-end marketplace workflows are ready for production.
Implementation: Documented separate frontend, backend, database, and workflow validation requirements. Added deployment safeguards, configurable environment settings, security headers, clearer failure states, and a release record that distinguishes implemented features from validation gaps.
Result: Created a more transparent operational baseline, with frontend type checking, scoped linting, Jest tests, and Django system checks documented separately from database-backed and full production validation.

Product capabilities