Asset Tracking Platform

The problem

An electrical contractor was tracking thousands of assets (tools, materials, and equipment moving between a warehouse and dozens of active job sites) across spreadsheets, texts, and people’s memory. Nobody could answer “where is this, and who has it?” without a phone call.

Note: details below are anonymized. No proprietary code or screenshots are shown. This describes the engineering, not the client’s product.

Context & scale

• Thousands of tracked assets across one warehouse and many simultaneous job sites.
• Field users on phones in low-connectivity environments; office users on desktop.
• The data had to stay trustworthy even when two people touched the same asset.

Architecture

I designed and built the system end to end:

• Data layer. A normalized PostgreSQL model treating every asset movement as an append-only event, so history is never lost and current state is always derivable.
• Backend. A Go service exposing a typed API, with optimistic concurrency so conflicting field updates resolve predictably instead of silently overwriting.
• Frontend. A React interface tuned for fast scanning and entry on a phone, with an office view for reporting.
• Infrastructure. Provisioned on AWS with reproducible deploys and backups.

Key decisions & trade-offs

• Event-sourced movements over mutable rows. More upfront modeling, but it made “where was this last Tuesday?” a query instead of an archaeology project.
• Optimistic concurrency over locking. Field users can’t wait on locks over flaky connections; conflicts are detected and resolved on write.
• Boring, proven tech. Go + Postgres because a one-person team can’t afford to debug the framework instead of the problem.

Impact

• Inventory reconciliation went from a multi-day chore to minutes.
• “Where is it?” became self-serve instead of a phone tree.
• One person could now own the whole lifecycle of the tool, in production.