Technical Work

Problems I've worked through

Real IT and systems problems, and how I worked through them.

Entries

Cutting receipt paper usage across POS operations

Cut receipt paper usage by 30%+ across POS operations. Real materials-cost savings, and less paper waste at scale.

The problem

POS terminals print a receipt for nearly every transaction, and at that scale, receipt paper is a real, ongoing cost. Nobody had taken a close look at how much of that could be cut without hurting the checkout experience.

What I built

LeanReceipt cut receipt paper usage by more than 30% at the register. That’s real money saved on materials, and real paper kept out of the waste stream at that scale. It worked well enough that Dollarcity, Dollarama’s Latin America division, picked it up too, on top of the original Canada rollout.

What it involved

Figuring out where the paper savings could come from without changing the checkout experience for customers or cashiers. Getting it validated well enough that it made sense to expand past the original Canada scope to Dollarcity as well.

Standardizing POS display profiles

Different POS hardware needed different dual-monitor profiles, with no fast way to switch between them out in the field.

The problem

POS terminals (ELO/NCR and Wincor hardware) need specific dual-monitor resolution profiles depending on how the second display is being used, and switching between them by hand through Windows display settings is slow on hardware that doesn’t give you a clean, unattended way to do it.

What I built

A menu-driven tool, written in PowerShell, that switches between resolution profiles directly instead of going through the display settings UI. Under the hood it calls the Windows Win32 display APIs, via embedded C#, to change monitor resolutions programmatically.

What it involved

Understanding how Windows exposes multi-monitor display configuration below the settings UI, and building something reliable enough to run against real POS hardware in the field (ELO/NCR and Wincor terminals) without needing a GUI walkthrough every time.

Building a home network stable enough for a smart home

Getting a home network reliable enough to run a smart home on top of it.

The problem

A home network has to hold up before you can put a smart home on top of it. Zigbee and Z-Wave devices need to talk reliably to whatever’s controlling them, and the router and switching setup underneath can’t fall over every time one piece changes.

What I built

Home Assistant, self-hosted on a Lenovo ThinkCentre mini PC, controlling Zigbee and Z-Wave devices around the house. It runs behind a network built around a GL.iNet Flint 2 router and a TP-Link managed switch, with the split between managed and unmanaged switching worked out deliberately, not left to chance.

What it involved

Getting Zigbee and Z-Wave devices talking reliably to Home Assistant took real troubleshooting, especially while migrating the setup between hardware. The bigger piece was designing the network itself, instead of plugging things in and hoping it held together.

Network layout

ISP fiber
→ GL.iNet Flint 2 (router)
→ TP-Link TL-SG108E (managed switch)
→ Room network outlets
→ NETGEAR GS105 (unmanaged switch, desk)

Running a homelab on hardware I already had

A homelab that runs Home Assistant and handles some self-hosting, built without buying new hardware for it.

The problem

I wanted a homelab that could run Home Assistant and handle some self-hosting, but not by buying a pile of new hardware just to get there. There was already older gear around that could handle it.

What I built

A homelab running almost entirely on hardware I already owned. Home Assistant handles the smart-home side, with the dashboards and automations written directly in YAML instead of through the built-in UI editor. It’s easier to see exactly what’s configured that way. The rest of it, file sharing and a few self-hosted apps, runs through runtipi on the same machine.

What it involved

Writing Home Assistant automations in YAML instead of the UI took some getting used to, but it’s much easier to track what’s configured. Some of the older hardware wasn’t worth keeping, so figuring out what to retire and what to reuse was its own small project. Getting runtipi set up so the self-hosted apps had somewhere reliable to run was the last piece.

Untangling password sprawl across four managers

Passwords scattered across four different managers, with no single clean source of truth.

The problem

Passwords had ended up scattered across four different places (Apple, Google, Bitwarden, and 1Password), with overlapping and duplicate entries between them and no single clean source of truth.

What I built

A set of local Python scripts that parse the export files from each of the four sources and deduplicate overlapping entries. Everything gets merged into a single clean CSV in Bitwarden’s import format.

What it involved

Understanding the different export formats each password manager uses, and writing deduplication logic that could tell duplicate entries apart from similar-but-different ones. All of it ran locally, not through any online service, given the sensitivity of the data involved.