Selected work
What this page is
Real projects with real users where possible, honest descriptions of scope, logic, fragility, and what I learned. Current work first, then the shop floor and the studies and the bakeries that got me here.
Current work
mCORE
Scope
A mobile-first carrier tool that does the small, specific things a carrier actually does every day. Grievance calendar math. Route forward tracking. Per-carrier color themes. Postal-math test suite with 63 passing assertions. Verifiable privacy mode. Event log with grandfathered honesty tags for pre-history records.
Logic
Most carrier tools are paywalled or look like they were designed in 2004. I built the one I wished I had on my route. Every feature is driven by a specific carrier at a specific case telling me what they needed. After sharing with a few coworkers, other carriers started asking for updates, often deployed the next day. The stack is intentionally small: static ES6 modules, localStorage, no backend, no auth, no sync (yet). That keeps it auditable.
Fragility
No backend means no account recovery. Clear your browser storage and your data is gone. The Route Forward Manager event log is append-only by discipline, not by constraint: I chose an invariant (never rewrite events) instead of enforcing it in code. The honesty fix for pre-history records (the grandfathered tag) is the open admission that I cannot retroactively reconstruct dates I never captured.
Learning
Sync is the hardest problem in this space, and also the one 80% of users do not need. I parked WebRTC live sync and shipped Phase A (event log) plus Phase B (encrypted blob exchange, in progress) instead. Sometimes the right call is to ship less and keep the thing fully auditable.
Repo: github.com/mailman-sam/mcore · Live: mailman-sam.github.io/mcore
Current work
RouteLog.wiki
Scope
A wiki for mail carriers to document route knowledge. Stops, CBUs, hazards, gate codes, dog locations, free-form notes. One wiki page per route, Wikipedia-style revision history, full revert. 21 real carrier users, 12 post offices, 146 map markers, 800+ activity events in the first six weeks.
Logic
Route knowledge walks out the door with every retirement. The institution pays roughly $4,000 to train a carrier, and new hires get thrown onto routes with little guidance because the person who knows the route is off that day. I built a wiki the older carriers are not afraid to touch and the new hires can actually use. Kept: stops, CBUs, hazards, revision history. Left out: management dashboards, scorecards, anything that smells like corporate metrics. Carriers do not want those, and the institution already has them.
Fragility
The site assumes carriers will contribute honestly. Spam and bad edits are not blocked at the schema level, they are handled by revision history: any edit can be reverted in one click. If the user base grows past the point where every contributor is known, this model has to be revisited. Authentication is login plus email verification; no admin role system yet (user id 1 is effectively admin). That is fine at 21 users and will not be fine at 2,000.
Learning
21 signups in 10 days, by word of mouth. Registration then broke at day 10 due to a missing SQL parameter and was invisible until a carrier messaged me. The 5 rounds of hardening that followed (secrets moved, rate limiter, email verification, authorization on edits, revision history) were written up as a public audit trail. The lesson: you speak to power by building the tool that would replace the thing power refused to build.
Live site: routelog.wiki/about
Current work
Custom Micro-Climate Controller
Scope
A sensor, aggregator, and dashboard stack for a climate-controlled room. Redundant temperature and humidity sensors. Aggregator that ignores the offline one. Cron-driven automations for scheduled events, dynamic thresholds for condition-driven events. Time series out to a Chart.js dashboard. Three cameras with live MJPEG plus snapshot API. Daily timelapse archive.
Logic
Off-the-shelf controllers did not fit my needs, and the ones that came close wanted a subscription to tell me the temperature. So I engineered the bridge myself. Normalization across redundant sensors prevents a single hardware failure from cascading into bad decisions downstream. Low-tech insight. Cost almost nothing. Stack: Raspberry Pi 4, temper-poll for USB temp sensors, go2rtc for cameras, bash and cron for orchestration.
Fragility
Single point of power failure (the Pi). If the SD card dies, the logs are gone unless the rsync off-box has run. No active alerting yet; I look at the dashboard when I remember. The security camera is on an isolated VLAN, which is why the default password has not been the top priority yet.
Learning
The aggregator pattern (ignore the offline sensor instead of erroring out) is the small design decision that makes the whole thing reliable. Anything that treats an offline sensor as a loud failure will turn every weekly Pi reboot into a fake alarm. Do not make the noisy choice.
Current work
Secure Environmental Monitoring
Scope
A hardened remote-monitoring appliance for my aging in-laws. Motion, contact, environmental, and eventually glass-break sensors. Home Assistant as the orchestration layer. Tailscale tunnel, no open inbound ports at their house. Industrial enclosure, utility-closet aesthetic.
Logic
My in-laws are aging into technology they cannot troubleshoot. I am building something I can remote into, patch, and reason about from my own house, so that they do not lose independence and so that we do not lose sleep. Tailscale instead of port-forwarding because their ISP and their skill level make inbound ports a non-starter. Home Assistant because it is the smallest useful orchestrator that will still be maintained in five years.
Fragility
Remote support depends on their home internet being up. No cellular fallback yet. The sensor mesh is Zigbee, which has a short-range failure mode I have not fully characterized at their floorplan. I am relying on their willingness to leave the enclosure plugged in, which is a social contract more than a technical one.
Learning
Autonomy of the resident is a harder success metric than uptime or efficiency. If the system works but they feel surveilled, the system has failed. Every design decision has to pass that filter: is this protecting them, or watching them? That is why the UI and the copy live with me, not with them. They should never have to interpret the sensor graph themselves.
Prior work
Manufacturing & Labor · 1990s
Started on a factory floor in packing and shipping. Moved to running tapping machines, then into Quality Control. Along the way I was selected for a pilot program in Kaizen, the Japanese continuous improvement methodology. That training rewired how I think about every system I have touched since.
During a union organizing effort, I used my technical knowledge to access and surface financial data that had been kept opaque. Gave the workers on the floor the same numbers the executives had. Transparency is a tool. I pointed it in the right direction.
This is where the pattern started. Not in a computer science program. On a shop floor, watching systems fail the people running them.
Prior work
Clinical Research Infrastructure · 2000s
Hired to coordinate studies at a clinical research facility. Within months I was pulling network cable, installing security systems, and standing up IT infrastructure nobody had budgeted for. The studies needed the data. The data needed the network. The network needed someone who would just do it.
Built the digital backbone of a research operation from bare walls. No vendor, no budget line item, no job description. Just a gap that was going to cost more to ignore than to fix.
Prior work
Logistics Transformation · 2010s
A manufacturer had a solid product and no way to get it in front of buyers efficiently. I built their entire web presence from nothing, redesigned the shipping workflow to cut friction out of fulfillment, and produced video content so their product could sell itself online.
They made a physical product. I built the digital pipeline around it. The product was already good. Everything between the product and the customer was not.
Prior work
Service & Hospitality · 2000s-2010s
Automated inventory and ordering systems for bakeries doing high volume. The manual process was bleeding hours every week. The ovens did not care about spreadsheets. The people running the ovens did. Replaced a system held together by memory and sticky notes with one that could survive a sick day.
Designed websites, logos, and full brand identities for small businesses across multiple industries. Bowling alleys, restaurants, personal care. They needed professional work at a price they could survive, and nobody else was going to deliver it. Each project started the same way: a business owner who knew their craft but could not translate it to a screen.