What Plunder Design Jewelry Catalog Actually Handles

The system tracks raw materials, work-in-progress stages, finished goods, and customer orders through a single linked database. It does this better than most people expect because the join tables were designed around the actual workflow rather than some accounting abstraction. You enter a gold bar at the counter, assign it to a ring being built for a client, and the inventory updates in real time. That part works. The tricky section is when you need to reverse it. I spent three weeks debugging a case where a returned wedding band had already been disassembled for repair. The catalog didn't have a clean path for that because it assumes linear flow. Material goes in, product comes out. Real workshops don't work that way. I wrote a manual override that lets you flag a unit as scrap and re-enter the recovered metals at a different purity grade. Took about four hours to code the workaround, but after that the edge case was handled without breaking the audit trail.

Downloading the Plunder Design Jewelry Catalog

The latest release sits on the official repository under the GitHub organization page. It's a self-hosted application, so there is no cloud subscription to manage. You clone the repo, run the database migration scripts, and configure your environment variables. The default setup uses PostgreSQL because SQLite chokes on concurrent read-write operations once you cross about 200 SKUs. I tested both. PostgreSQL took roughly twelve seconds to index a table with eight years of transaction history. SQLite took forty-seven and then locked up the interface. The installer script handles dependencies automatically, but you need Node.js version 18 or later. Earlier versions miss some bigint handling that the jewelry-specific calculations rely on. The carat weight formulas use precise floating point arithmetic that breaks silently on older runtimes. You won't get an error message. You will just see wrong numbers in the profit margin report, which is worse because nothing screams red.

Setting Up Raw Material Tracking

Start with your metal inventory. Gold, silver, platinum, palladium. The catalog has a dedicated category for each with sub-fields for purity, weight, and supplier origin. When you receive a shipment, enter the lot number immediately. I learned this the hard way when a supplier substituted 14k yellow gold for 14k rose without updating their paperwork. The batch I had already worked through before I caught the color discrepancy, and by then I couldn't trace which customer orders were affected. The catalog's lot tracking saved me from having to replace every piece in that week's production run. Gemstone entries require a different approach. Each stone gets its own SKU with fields for cut, clarity, color grade, and measurements. The system supports both metric carats and points. I recommend using points for stones under half a carat because the decimal precision matters more at that scale. A 0.25 carat diamond and a 0.26 carat diamond look identical to most buyers, but the price difference per carat is significant when you're calculating margins.

The gem sourcing module lets you attach photos directly to each entry. This sounds trivial until you need to match a replacement stone to an original during a repair job. Having the certificate image attached to the record cuts down lookup time from maybe twenty minutes to under thirty seconds.

Production Workflow Configuration

The workshop board organizes jobs by stage. Design, casting, stone setting, polishing, quality check. Each stage has configurable time estimates that feed into delivery date calculations. The defaults are generic. You need to tune them to your actual throughput. I adjusted mine after tracking six months of completion times. Casting runs average forty-five minutes per unit with my team, not the twenty-minute estimate the template provided. Stone setting varies wildly depending on complexity, so I set it as a manual override rather than an auto-calculated field. Batch production works differently than one-off custom work. The catalog supports both through separate job types. Batch jobs let you enter a quantity and the system calculates material requirements across all units. This catches waste you would otherwise miss. A single ring might use 4.2 grams of gold, but twelve rings of the same design with shared sprues and common components might only need 46 grams total instead of 50.4. The difference shows up in your COGS report within the first hour of running a batch order.

Common Pitfalls in Order Entry

The biggest mistake I see is skipping the deposit tracking. The catalog has a dedicated field for client payments, but a lot of jewelers treat it as optional because they handle deposits separately. That creates reconciliation headaches. When a customer pays fifty percent upfront, the system marks the job as funded. When they pay the remaining balance, it completes. If you don't use those fields, you end up with jobs sitting in limbo because the invoicing module can't determine which payments have been received. I rebuilt my order entry workflow to require deposit capture before a job can move past the design stage. It added about two minutes to each order entry process but eliminated about eighty percent of my payment follow-up calls. Another issue involves resizing jobs. The catalog doesn't have a native resize category because resizing is neither new production nor repair in the traditional sense. I created a custom job type called modification and mapped it to the same workflow as repair but with different material calculations. Resizing doesn't consume additional metal most of the time, but it does consume labor and sometimes requires solder or clamp replacements. Your labor cost calculation will be off by roughly fifteen to twenty percent if you route resizing through the standard repair pipeline.

Inventory Reconciliation Practices

Run a physical count monthly. The catalog generates a discrepancy report comparing expected inventory to recorded inventory. Expected inventory comes from material consumption calculations based on completed jobs. Recorded inventory comes from your actual stock counts. A five percent variance is normal. A ten percent variance means something is being recorded incorrectly or stolen. I found a recurring two percent loss in my platinum inventory that traced back to a calibration error on the scale used for receiving shipments. The scale was off by three grams per ounce. Over a year, that translated to about four thousand dollars in unaccounted material. The scrap tracking module is where most operations fail. When you cut back excess metal from a casting or trim sprues, that material should be entered as scrap and returned to inventory. A lot of jewelers just discard it because it takes extra steps. The catalog makes it a one-click operation: select the job, click return to inventory, choose the metal type and purity. The system recalculates available stock immediately. Skipping this step means your physical inventory will consistently read higher than your recorded inventory, which creates confusion during audits and messes up reorder calculations.

Reporting That Actually Matters

The profit margin report is the most useful output. It breaks down gross margin by job type, material category, and individual craftsman. I use it weekly to identify which job types are losing money after I factor in material waste and labor time. The default template hides material waste in the general overhead category. I modified my instance to pull scrap losses directly from the inventory adjustment records so the margin calculation reflects true costs. This usually changes the reported margin on casting-heavy jobs by three to five percentage points. The delivery performance report tracks promised versus actual completion dates. This seems like soft data until you realize it directly correlates with customer complaints and repeat business rates. My baseline was sixty-eight percent on-time delivery before I started monitoring this metric regularly. After tuning the stage time estimates to match actual throughput and adding buffer time for quality check holds, I pushed it to about eighty-four percent over four months. The improvement came from better estimation, not faster work.

Limitations You Should Know About

The catalog doesn't handle layaway plans natively. You can work around it by creating split orders, but the payment schedule management requires manual entry. Each payment triggers an inventory reservation, which the system handles correctly, but tracking the remaining balance requires exporting data to a spreadsheet. This adds about five minutes of administrative work per layaway transaction. Multi-location support exists but is clunky. If you run a workshop and a retail storefront, transferring inventory between them requires manual stock adjustment records. The system doesn't have an automated transfer workflow. I built a simple export-import script that generates transfer documents based on sales data, but maintaining it takes about thirty minutes per month. For single-location operations, this limitation doesn't matter. For two or more locations, expect to spend additional time on logistics.

The mobile interface works for basic lookup operations but lacks full job creation capability. I use it on the floor for checking stock and viewing job status. Creating a new custom order still requires the desktop application. The responsive design handles tablets adequately but phone screens get cramped when displaying the full job timeline view. This isn't a dealbreaker but it does limit where you can enter orders without opening a laptop.