HCMDB: Building a B2B Diamond Exchange with Millions of Stones
The Problem: Importing Diamonds Legitimately Is Hard
For a Vietnamese diamond retailer, importing stock legitimately from India, Hong Kong or Dubai is neither easy nor cheap. HCMDB was built to do one clear thing: connect domestic retailers directly with the world's diamond centers, B2B, so that import becomes easier and more transparent.
I joined as Project Manager and Full Stack Developer. I coordinated the team's progress, shaped the architecture, and wrote code on both the frontend and the backend, which runs on NestJS with PostgreSQL.
From Paperwork to Stones: A Controlled Marketplace
HCMDB isn't an open market. Users register, submit legal documents, and an admin approves them before they can trade. In an industry where trust is the biggest asset, this step isn't bureaucracy. It's part of the product.
Once approved, a retailer searches for stones, adds them to the cart, sees the total including import tax and shipping, and places the order. Suppliers get their own screens to list and manage their stones.
Why Flutter for a B2B Platform
From day one the plan was a web product first, then mobile. Maintaining two separate codebases is the fastest way for a small team to slow down, so I chose Flutter: one codebase, shipped to web and later to apps.
That choice had a price I accepted deliberately. Flutter Web isn't friendly to SEO. But HCMDB is a trading platform, users must sign in to see inventory, and the app doesn't need SEO. The parts that do need to be found, the landing page, registration and articles, live on a separate lightweight website.
The Real Challenge: Millions of Stones, Hundreds of Thousands per Filter
What makes this project different from an ordinary commerce app is the scale of the data. The inventory runs into the millions of stones, and each time a user filters by shape, color, clarity or weight, the result can be hundreds of thousands of stones.
In this business a laggy filter is a filter nobody uses. So the app never tries to hold the whole inventory in memory. Filter conditions go to the server, and the app only receives one page of results along with the total count and total value, rendering exactly what the user is looking at. Syncing the stones and the news feed also fell within my scope.
Architecture: Let Everyone Work Without Stepping on Each Other
With many people committing at once, the first thing to break is the boundary between features. I structured the app in separate layers: UI, state logic, repositories and the API layer. Every network call goes through a single place.
So whoever builds the cart doesn't need to understand how the diamond filter works, and whoever fixes the filter doesn't break the order screen. The repo history shows more than six hundred commits from many contributors over a few months, and the structure held well enough that nobody had to wait for anybody.
What I Took Away
What I carry from HCMDB isn't a Flutter trick. It's that technology choices should start from the product's plan, not the team's preferences: need many platforms, pick one codebase; don't need SEO, don't pay for it. And for a large team, good architecture isn't about elegance. It's about letting many people work at once without stepping on each other.
Tech Stack
Flutter
Dart
Firebase
Sentry
NestJS
PostgreSQL