Inventory system

DIMS

One diamond inventory and request system shared across three offices.

Role: Sole builder. Backend, frontend, and desktop app.
Status: In development
Year: 2026

Code walkthrough on request Start a project

Screens captured from DIMS running locally with fictional demo stock. The production system has been retired.

How it works, end to end. The screens inside are real captures; every command and stage is the project's own.

The problem

Sales reps in New York, Chicago, and Los Angeles were browsing separate, disconnected stock, so requests for the same stone could collide, and inventory staff had no single source of truth for what was in stock, on memo, on hold, or already requested.

What I did

Built the backend, frontend, and desktop app end to end, including the review-first request workflow and the document extraction pipeline.

How it works

One login system over combined loose-diamond and jewelry stock for all three offices, availability protection against duplicate requests, barcode and pasted-detail intake, and PDF and invoice extraction that always requires review before anything is sent.

DIMS request screen: a New York rep with stones from Chicago in the cart and the home branch detected. — A rep's request: home branch detected, branch transfer flagged before anything ships.

DIMS inventory screen showing a CH to NY shipping request awaiting confirmation. — Inventory sees one job: CH to NY, ship.

DIMS stock and upload screen with diamond filters across all three offices. — One stock view across New York, Chicago and Los Angeles.

The hard parts

01
Stopping two reps in different offices from requesting the same physical stone at the same moment.
02
Extracting stock details from pasted text and PDFs reliably enough to trust, while keeping a person in the loop before anything ships.

What changed

Three offices share one inventory view, with duplicate requests blocked before they reach staff.
The review-first request flow removes double booking entirely.

Built with