Loadatum is a tracker built for handloaders, people who reload their own ammunition. Reloading generates a lot of data: component inventory, load recipes with safety-relevant charge weights, production batch logs, and range session results. Without a dedicated tool that data usually ends up scattered across spreadsheets, notebooks, and memory, which makes it hard to actually learn from your own history, like which load shot best out of a particular gun. Loadatum puts all of it in one place, built mobile-first since most of the data entry happens standing at the range.
Tracking Brass Life Safely
Brass is the one reusable component in reloading, and it weakens with every firing. The app tracks a firing count per case lot, but the hard part was handling what happens when that number isn't cleanly knowable. A freshly bought box of brass starts at zero firings, but range-pickup brass has an unknown history that can't be silently treated as zero, since that would understate how worn it actually is. The fix was a nullable firing count that distinguishes "known, zero" from "unknown," a per-lot warning threshold that falls back to a global default, and treating retirement as an advisory warning rather than something the app enforces. That call belongs to the reloader, not the app.
A Shared Catalog Behind Private Inventory
Components aren't modeled as simple tables a user owns outright. Each component type splits into a shared catalog, which supports a nullable owner so entries can be global or user-private, and a separate per-user inventory tracking how much of it someone has. It's more query complexity than a single owned table, but it was necessary to support a public reference-load browser: a user can look at a published recipe built from catalog components without first being forced to own every component in it.
Gating Analytics History by Query Parameter
Free-tier accounts get a rolling window of analytics history instead of full history. That gate is applied as an explicit parameter passed into the analytics queries themselves, deliberately not a global Eloquent scope, so it can't silently leak into and break unrelated queries like batch creation or inventory lookups.
A Refactor That Rippled Through Every Caller
A mid-project schema change split the component tables from single "one row per user" tables into the catalog-plus-inventory model described above. The services were updated first and were correct, but everything that called them, Livewire pages, API controllers, and the test suite, still assumed the old method names, DTO shapes, and column names. The test suite caught every one of those breakages at once, and there was no single root cause to patch: it took going caller by caller to reconcile each consumer with the new shape.
Loadatum runs on Laravel, Livewire, and Alpine.js, with Stripe handling subscription billing, Redis backing the cache, and Chart.js driving the analytics views.
