Offline-first desktop inventory tracker for panel & body manufacturing component tracking.
Built with Electron, React, and a local SQLite database — no server, no internet connection, no monthly bill. Just fast, indexed, reliable inventory control that lives on the shop floor's own machine.
Stockyard was built to replace manual spreadsheet reconciliation for tracking physical components on a manufacturing floor — panels, body parts, fasteners, sub-assemblies — with a single-file, installable desktop application that works entirely offline. It reduced manual reconciliation effort by up to 66% by moving stock counts, low-stock alerts, and bill-of-materials coverage checks out of shared spreadsheets and into a real, indexed, transactional database with a purpose-built UI.
It runs as a native Windows desktop app: double-click, no login, no cloud dependency, no internet required. All data lives in a single SQLite file on the machine it's installed on.
Spreadsheet-based inventory tracking on a manufacturing floor breaks down in predictable ways:
- No enforced structure — two people can name the same SKU differently, or overwrite each other's edits.
- No real audit trail — "who took the last 10 units, and when?" has no good answer.
- No automatic alerting — stockouts get discovered when someone walks to the shelf, not before.
- No fast lookup — searching a 5,000-row spreadsheet by SKU or location is slow and error-prone.
Stockyard solves each of these directly: every stock change is a recorded transaction (not an overwritten cell), every search hits an indexed SQL query instead of scanning rows in memory, and a background engine continuously watches stock levels so shortages surface automatically instead of being discovered on the floor.
- Full component catalog with SKU, name, category, quantity, unit, location, cost per unit, supplier, and free-form notes.
- Configurable low-stock threshold and optional max stock per item, with category-level aging windows (flag components that haven't moved in N days).
- Soft-delete support — items are archived, not destroyed, so historical transactions stay intact.
- Barcode scanner support out of the box: keyboard-wedge scanners are detected by keystroke timing (fast bursts terminated by
Enter), distinguishing a scan from normal typing without any special hardware driver.
At-a-glance KPI cards — total SKUs, out-of-stock count, low-stock warnings, aging components, and total inventory valuation — plus a critical-shortages table so the most urgent items are always visible first.
A scheduled job (interval configurable in Settings) continuously scans inventory and raises alerts with severity levels:
| Alert type | Severity | Trigger |
|---|---|---|
OUT_OF_STOCK |
Critical | Quantity reaches zero |
LOW_STOCK |
Warning | Quantity falls at/below the item's threshold |
AGING |
Info | No recorded movement within the category's aging window |
Alerts can be acknowledged (snoozed) or resolved, and trigger native OS notifications so a shortage doesn't sit unnoticed in a background window.
Every stock change — receipt, issue, adjustment, or initial count — is written as an immutable transaction row with the quantity delta, the quantity before the change, the operator who performed it, and an optional reference (PO number, build name). Nothing is ever silently overwritten.
Define BOM templates (a named list of components + required quantities) and instantly check coverage — how many complete units can be built right now given current stock — without manually cross-referencing the inventory sheet.
- One-click CSV export (native OS save dialog) for inventory, transactions, or alert history.
- One-click raw
.sqlitedatabase backup. - Factory reset / wipe for a clean slate on a new install.
Stockyard follows a multi-process local client–server pattern — the same shape as a web app's frontend/backend split, just running entirely on one machine. This keeps the UI thread free of database work and keeps filesystem/database access out of the (sandboxed) renderer entirely.
┌──────────────────────────────────────┐
│ RENDERER PROCESS (React UI) │
│ - Captures filters and input search │
│ - Debounces input state (250ms) │
│ - Renders paginated data tables │
│ - Sandboxed: no direct filesystem access │
└──────────────────┬─────────────────────────┘
│
│ Asynchronous IPC Bridge (contextBridge, contextIsolation: true)
▼
┌──────────────────────────────────────┐
│ MAIN PROCESS (Node.js) │
│ - Receives IPC requests (API gateway) │
│ - Handles file I/O (CSV export, backup) │
│ - Runs the background alert engine │
│ - Fires native OS notifications │
└──────────────────┬─────────────────────────┘
│
│ Drizzle ORM → indexed SQL queries
▼
┌──────────────────────────────────────┐
│ SQLITE DATABASE (single file) │
│ - better-sqlite3, synchronous, in-process │
│ - Indexed on sku, name, category, location, │
│ deletedAt, createdAt │
└──────────────────────────────────────┘
- Process isolation. The renderer runs
contextIsolation: true,nodeIntegration: false,sandbox: true. It has zero direct filesystem or Node.js access — every operation crosses through a typedpreload.tsbridge intoipcMainhandlers in the main process. A compromised or buggy UI can't touch the database or disk directly. - Server-side filtering & pagination. Search, category filters, and status calculations run as SQL in SQLite, not as array filtering in React state — results are paged with
LIMIT/OFFSET(100 rows/page) to keep memory flat regardless of catalog size. - Indexed reads. Explicit indexes on the columns actually used for filtering and sorting (
sku,name,categoryId,location,deletedAt,createdAt) keep lookups fast even as the transaction ledger grows into the tens of thousands of rows. - Debounced input. Search inputs debounce at 250ms client-side before dispatching a query, avoiding a database round-trip on every keystroke.
- Background scheduled services. The alert engine runs on a timer inside the main process (independent of whether a UI window has focus), so alerts stay current even if the user is on a different tab.
- Append-only transactions. Stock changes are never in-place updates to a "current quantity" field alone — every change is logged as a new
transactionsrow with a before/after delta, making the transaction ledger a true audit trail.
| Layer | Technology | Purpose |
|---|---|---|
| Desktop shell | Electron 31 | Cross-platform native desktop runtime |
| Frontend UI | React 18 + TypeScript | Component-based renderer |
| Build system | Vite 5 + vite-plugin-electron |
Bundling & hot-reload for both processes |
| State management | Zustand 4 | Lightweight global store (inventory, alerts) |
| ORM | Drizzle ORM + drizzle-kit |
Type-safe schema, queries, and migrations |
| Database | SQLite via better-sqlite3 |
Synchronous, in-process, single-file storage |
| Charts | Recharts | Dashboard visualizations |
| Icons | Lucide React | Icon set |
| Packaging | electron-builder (NSIS) | Windows installer generation |
Five tables, fully typed end-to-end via Drizzle's inferred select/insert types:
| Table | Purpose |
|---|---|
categories |
Component categories, each with a configurable aging window (days) and a UI badge color |
items |
The component catalog — SKU, quantity, threshold, location, cost, supplier, soft-delete flag |
transactions |
Append-only stock movement ledger — type, quantity delta, before-quantity, operator, reference |
alerts |
Generated by the alert engine — type, severity, active/acknowledged/resolved state |
bom_templates / bom_items |
Named BOM configurations and their required component quantities (composite PK) |
All communication between the UI and the database goes through a fixed set of asynchronous IPC channels exposed via the preload bridge — effectively the app's internal API surface.
Categories
categories:getAll— fetch all categoriescategories:create/categories:update/categories:delete
Items / Inventory
items:getAll— raw dumpitems:getFiltered— paginated + filtered (used by tables)items:searchAutocomplete— quick SKU/name lookupitems:getLocations— distinct warehouse/shelf locationsitems:getSimpleList— minimal metadata (ID, SKU, name)items:getById— full detailitems:create/items:update/items:deleteitems:adjustStock— register a stock adjustment transaction
Transactions
transactions:getAll/transactions:getFilteredtransactions:getOperators— distinct operator listtransactions:getByItem— history for one item
Alerts
alerts:getActive/alerts:getResolvedalerts:acknowledge/alerts:resolvealerts:updated— event fired when the background engine raises new alerts
Bill of Materials
bom:getAll/bom:getDetailsbom:create/bom:update/bom:deletebom:checkCoverage— compare a BOM against current stock to compute buildable quantity
Export & Settings
csv:export— native save-dialog export to CSVsettings:getSchedulerInterval/settings:setSchedulerIntervalsettings:runAlertScan— force an immediate scansettings:backupDB— raw.sqlitefile backupsettings:resetData— factory reset
Stockyard/
├── build/ # App icons & packaging static assets
├── dist-installer/ # Packaged Windows installer output (generated)
├── drizzle/ # SQL migrations (generated by drizzle-kit)
├── electron/ # Main process (Node.js)
│ ├── database/
│ │ ├── connection.ts # DB connection init + migration runner
│ │ ├── schema.ts # Table schemas, indexes, inferred types
│ │ └── queries/ # Query handlers (items, transactions, alerts, bom, categories)
│ ├── services/
│ │ ├── alertEngine.ts # Stock-level scan → alert generation
│ │ ├── scheduler.ts # Interval-based background scheduling
│ │ ├── notifier.ts # Native OS notification dispatch
│ │ └── csvExport.ts # CSV export via native save dialog
│ ├── main.ts # Entrypoint, window creation, IPC registration
│ └── preload.ts # contextBridge — the only surface the renderer can call
├── src/ # Renderer process (React)
│ ├── components/layout/ # App shell / navigation layout
│ ├── hooks/ # useInventory, useAlerts, useBOM, useScanner
│ ├── lib/ # Typed IPC client wrapper
│ ├── pages/ # Dashboard, Inventory, Transactions, Alerts, BOM, Settings
│ ├── store/ # Zustand stores (inventory, alerts)
│ └── main.tsx # React bootstrap
├── docs/ # Technical specification
├── package.json
└── tsconfig.json
- Node.js ≥ 18
- npm
- Windows (current packaging target — see Platform support)
# install dependencies
npm install
# run the Vite dev server + hot-reloaded Electron shell
npm run dev# generate a new migration after editing electron/database/schema.ts
npm run db:generate
# open Drizzle Studio to inspect the local database
npm run db:studio# compile TypeScript and bundle optimized assets
npm run build
# package into a standalone Windows installer (.exe) — runs the build step automatically
npm run electron:buildThe installer is emitted to dist-installer/.
Stockyard stores everything in a single SQLite file inside the OS application-data directory — no external database, no network calls, and no telemetry:
| OS | Path |
|---|---|
| Windows | C:\Users\<Username>\AppData\Roaming\stockyard\inventory.db |
Use Settings → Backup Database to copy this file out for safekeeping, and Settings → Reset Data to wipe it and start clean.
Current electron-builder configuration targets Windows x64 (NSIS installer) only, matching where it's deployed today. The Electron/React/Drizzle core has no Windows-specific code paths, so macOS/Linux targets could be added to electron-builder.config.js without core changes if ever needed — just untested today.
- Renderer runs fully sandboxed (
sandbox: true,contextIsolation: true,nodeIntegration: false) — the UI cannot touch the filesystem, spawn processes, or access Node APIs except through the explicit, typed IPC surface documented above. - Operator names are trimmed and capped at 100 characters before being written to the transaction ledger.
- All queries go through Drizzle's parameterized query builder — no raw string-concatenated SQL.
Internal tool — © Aditya Singh. Not currently published under an open-source license.