Skip to content
All work
Software DevelopmentITADAsset RecoveryInventory SystemsRefurbishmentCommercial Projects

ITAD Inventory & Asset Disposition Platform

A production system for IT asset disposition: receiving, hardware audit, grading, refurbishment, sales and compliance certification. It replaces a spreadsheet-and-memory process with one auditable record per device, and it issues the data-erasure certificates the industry actually gets asked for.

Role
Sole designer, architect and engineer
Client
ALS Trade Wholesales
Timeline
Jan 2025 — Present
Status
live
NestJSNext.js 15TypeScriptPostgreSQLTypeORMPowerSyncRailwayVercelPDFKitBash
The ITAD platform dashboard showing lot roll-ups and device counts
Tracking granularities
3Serialised devices, bulk SKUs, and mixed-quantity pallets — the three ways stock physically arrives.
Lifecycle stages modelled
10Receive → verify → sort → audit → grade → refurbish → inventory → sales → compliance → reporting.
Records destroyed on sale
0The tool it replaced deleted assets after sale. History here is append-only.

The problem

IT asset disposition looks like a logistics problem and behaves like a compliance problem. A pallet arrives with a supplier manifest that is optimistic at best. Every device on it has to be identified, tested, graded, wiped, priced and sold — and at the end of that chain a client can ask you to prove, in writing, that their data was destroyed. The existing tooling handled the first half and actively worked against the second: it deleted asset records once a unit was sold, which is precisely when the audit trail starts to matter. The rest of the process lived in spreadsheets and in people's heads.

Research

I started from the floor rather than the schema. I mapped the real path a device takes through the warehouse and found that the single assumption baked into the old system — that every item is an individually serialised unit — was false for most of the stock. Keyboards, mice and cables are counted, not serialised. Monitors arrive on mixed pallets described as '20 × 22-inch, 35 × 23-inch'. Those two categories were being kept in Excel because the software could not represent them. That finding reframed the whole project: the core modelling problem was tracking granularity, not workflow.

Planning

I wrote the redesign as a sequence of phases that could each ship to production independently, starting with a product catalogue and ending with compliance certification. The constraint I set was that the system had to stay live and usable throughout — this is a working warehouse, not a greenfield project. Every phase was deployed and verified against the production API before the next one started.

Design

Three tiers of tracking sit side by side: serialised assets with a unique tag and full history; bulk stock lines with an append-only quantity movement log; and pallets with per-variant line quantities. Above them sits the purchase lot — the commercial unit a buyer actually thinks in. The operational interface was later rebuilt around lots rather than individual devices, because at a few thousand units a device-first list stops being usable. Lot cards carry live roll-ups: scanned against expected, missing, extra, ready for sale, scrap, quarantine, audited.

Architecture

A NestJS API on Railway with self-hosted PostgreSQL, and a Next.js 15 App Router frontend on Vercel. PowerSync provides offline-first sync so warehouse scanning keeps working when the WiFi does not — the device holds a local SQLite replica and uploads a write queue on reconnect. Hardware capture happens outside the web stack entirely: a bootable Linux tool posts device specifications straight into the API. Full hardware profiles are stored as JSONB so new capture fields need no migration, with only the fields that must be searchable promoted to indexed columns.

Architecture diagram: bootable audit tool and web client both writing to a NestJS API backed by PostgreSQL, with PowerSync providing offline replication

Challenges

  1. 01

    Intake devices have no operating system

    The obvious way to collect hardware specifications is an agent running on the device. That is useless here — most units arrive already wiped, with no OS to run an agent on. I built the capture tool as a bootable Linux script instead, reading DMI, lscpu, lsblk, SMART, PCI and sysfs directly. It boots from USB, identifies the machine, and uploads a complete profile without the device ever having an installed operating system.

  2. 02

    The audit tool mis-identified machines as their own boot stick

    The first real field run reported a ThinkPad as a SanDisk USB drive. The storage loop was using eval on lsblk -P output, which defined shell variables literally named MODEL and SERIAL — clobbering the system's DMI identity that had been read moments earlier. I removed the eval, parsed into namespaced variables, and restricted the audit to internal fixed drives only. A parsing shortcut had silently overwritten the machine's identity.

  3. 03

    Offline writes were being dropped silently

    Warehouse scanning worked offline, then quietly lost data on sync: every multi-word snake_case column failed to map on upload. Separately, a deleted lot left a dangling foreign key that wedged the entire upload queue — one bad reference blocked every subsequent write. Both were fixed with explicit mapping and FK sanitisation, but the lesson was that an offline queue fails silently by design, so it needs its own verification path.

  4. 04

    Firmware erase is not one command

    Issuing a credible erasure certificate means actually purging the drive. Field testing showed the theory does not survive contact with real hardware: a Dell NVMe drive advertised no crypto erase via FORMAT but supported it via SANITIZE. SATA drives are usually security-frozen at boot, blocking ATA secure erase entirely. The tool now dispatches across NVMe format, NVMe sanitize, ATA secure erase and overwrite, with method-aware verification — an overwrite must read back as zeros, a crypto erase cannot, so it is recorded as controller-confirmed instead.

The solution

One device, one permanent record, from arrival to invoice. Stock arrives as a purchase lot with an imported supplier manifest; receiving reconciles expected against scanned and reports found, missing and extra. A bootable USB tool captures the full hardware profile and can perform a verified NIST-grade erase in the same pass. Grading and functional testing stay human, because judgement does not automate well. Repairs are logged with parts and cost, which flows into per-unit profit. Sales pick devices by serial, and shipping a unit flips its status and writes an immutable history entry rather than deleting it. At any point after a recorded wipe, the system will issue a per-device or per-lot Certificate of Data Erasure as a PDF — and refuses to issue one where no completed wipe exists.

Result

The platform runs the business it was built for. The process that lived across spreadsheets, a legacy tool and institutional memory is now a single auditable system, and the compliance artefact that used to be assembled by hand is generated from the erasure record itself. The refusal case matters as much as the feature: a certificate can only exist where the wipe genuinely happened.

What I took from it

  • Model the physical reality before the workflow. The most expensive assumption in the old system was that everything is serialised — a workflow decision made at schema level years earlier.

  • Ship in phases against production. Deploying each stage into a live warehouse surfaced modelling errors that no amount of design review would have caught.

  • Offline systems fail quietly. Every failure I found in the sync layer was silent — no error, just missing data. Offline capability needs deliberate verification, not just testing that it works.

  • Build the refusal path. The certificate generator declines to issue where no wipe is recorded, and that constraint is the actual product.

  • Field-test hardware assumptions early. Every erase method I implemented from documentation behaved differently on real drives.

Roadmap

  1. Full-lifecycle ITAD workflow (complete)

    Receiving through sales, costing and profit reporting.

  2. Comprehensive hardware audit (complete)

    Bootable capture of every hardware category into an extensible JSONB profile.

  3. Verified data erasure + certification (complete)

    NIST-aligned purge with method-aware verification and PDF certificates.

  4. WEEE & environmental reporting (planned)

    Extend the compliance stage to environmental and ESG reporting obligations.

  5. Certificate register (planned)

    In-app company settings, signatory details and a searchable register of issued certificates.

  6. Scale hardening (planned)

    Move remaining client-side aggregation into database roll-ups ahead of six-figure device counts.