One summer afternoon I was looking out a window at work.

A man from our admin office was walking the parking lot in the blazing heat. He had a notebook in his hand, and he was copying down car license plates one by one.

Our hospital had two lots: one for staff, one for visitors. Sometimes staff parked in the visitor spots, and then real visitors had nowhere to go. This man’s job was to track down the owner of each misparked car and ask them to move it.

The walk that bothered me

Here is how he did it.

He wrote the plate numbers in his notebook. He walked back inside. He opened an Excel file — an emergency contact list. He matched each plate against the file by hand to find the owner. Then he called that person and asked them to move their car.

Watching him do this made me feel bad. The heat. The notebook. The walk back. The digging through a file. All of it, just to ask one coworker to move one car for a couple of minutes.

And here is the thing that stuck with me: the data was already there. The plate numbers, the staff phone numbers — all of it lived inside that one Excel file.

So why carry it back to the office at all?

My first tool that lived outside the office

What if he could stand right there in the lot, type a plate number into his phone, see the owner’s name, and call them on the spot?

That would erase the notebook, the round trip, and the file-digging in one move.

So I built it. You open it on your phone, type in a plate number, and the owner appears. Tap one button to call them. Tap another to text them. That was the whole thing.

I gave it a name — a plain one, just “find the car,” shortened to EasyCS. It was the first of the “Easy” tools that now run at the hospital. There are more than twenty of them today. This little one was number one.

I didn’t realize it at the time, but this was also the first tool I made for someone to use outside the office, standing in the field. That detail seemed small. Later, building things people use out in the world opened a very big door. But that is a story for another day.

Then I started seeing it everywhere

Once you notice this kind of thing, you can’t stop noticing it.

Our infection-control office had one person too. Hospitals regularly check how well staff follow hand hygiene — it is one of the most basic ways to stop infections from spreading. So this coworker walked the building, watched whether people washed their hands properly, wrote it down on paper, then typed it all into Excel to produce statistics.

There used to be an outside program that did the math for her. Then the contract ended. Overnight, the whole job landed back on one person — someone who wasn’t even comfortable with Excel. She was building formulas by hand, late at night, then reshaping the results into a separate report to submit to a national infection-data registry.

When I looked at her checklist, it asked only a handful of questions. It was simple. I couldn’t understand why something this simple was costing one person so much.

So I built that one too. Tap the answers on your phone in the moment, and the results organize themselves and the statistics come out the other end. The work she had carried alone shrank to a few taps. That tool became EasyHO.

It was always the person first

Looking back, I always saw the person before I saw the problem.

Inefficiency is never abstract. It is always someone, somewhere, spending real hours on work that shouldn’t exist — sweating in the heat, or stuck late at night on a task they were never trained for. I just couldn’t walk past that.

I wasn’t thinking I’m going to build software. I was thinking I wish that person had it a little easier. That was the whole motive. The tools came second.

If you are waiting for the perfect idea before you start, here is the one I’d offer instead: don’t look for a problem worth solving — look for a person worth helping, and the problem will be obvious.

That single shift is what kept me going. A vague “this is inefficient” is easy to ignore. A specific tired coworker is not.

Where it started to break

Building one small tool, then another, worked fine when only a few people used them.

But the tools kept growing, and the data kept getting bigger. At some point everything I had been leaning on started to shake under my feet.

That is where the real trouble — and the real learning — began. More on that next time.