Hired to analyze.
Ended up building.

QR equipment system

The original problem was simple: equipment in the field should be identifiable without someone having to search through another system.

I built a QR-based tool around that interaction. Scan the equipment, pull up the relevant record, and get the information you need.

The office side supports creating equipment records and generating the QR labels that connect the physical asset back to the system.

None of this is supposed to feel impressive to the person using it.

That is kind of the point.

If scanning the code requires training, I have already made it too complicated.

Next.js · Supabase · Deployed

Scale movement tracking

Equipment moves. The database does not magically move with it.

I built a web workflow that lets office staff look up a scale, see where it is currently recorded and where it belongs, then report a move or flag equipment that cannot be located.

Those changes do not immediately rewrite the source system. They go through an office review first, and approved updates can then be passed back through an external API.

I wanted the workflow to fit around how the team already handles equipment rather than introduce an entirely new operating process.

The tool handles the movement. People keep the judgment.

Workflow design · API · Internal tool

Credit card statement builder

This one started with a monthly finance process that involved separating transactions by cardholder, assigning G/L codes, reviewing receipts, and building the final workbook by hand.

I built a local browser tool that reads the statement and prepares the report.

The first version was not good enough.

It could match merchants and suggest codes, but too many of those suggestions were wrong. Worse, a perfectly balanced report could still contain a perfectly wrong G/L code.

So the problem changed from:

“Can I automate this?”

to:

“What is safe to automate?”

Now confirmed merchant rules can be reused, uncertain matches are surfaced instead of silently accepted, users can skip or flag individual codes, and the balance check explicitly does not pretend to validate accounting judgment.

I also removed card numbers from the tool rather than trying to make storing them safer.

The goal is not zero human review.

The goal is to make sure the human spends time on the things that actually require judgment.

Python · Finance workflow · Human-in-the-loop

Analysis people can actually interrogate

Not every problem needed an application.

Sometimes the useful thing was taking a messy operational question and making the answer explorable instead of handing someone another static report.

One example started with a simple concern: activity in part of the business appeared to have fallen significantly.

I classified several years of work orders and built an interactive customer-mix analysis that let the team compare periods, isolate individual customer groups, and remove unusual project work from the picture.

The interesting part was what happened when you started taking the data apart.

The business had not simply moved in one direction. The customer mix had changed significantly, and one unusually large project could make a year look much stronger than the underlying recurring business actually was.

I use the same approach for other recurring reports and operational analyses: automate the repetitive preparation, then make the exceptions and decisions easier to see.

The useful output is rarely everything the system knows. It is the part someone needs to look at next.

SQL · Python · Interactive analysis