Almost a year ago, I built my first proper automation. It started as a small Google Form fix for messy photo uploads but became a full workflow change. That moment was when I realized what it really means to solve problems with code.
The issue looked simple: photos for auction lots were being dumped into one folder with random names, making it impossible to match them to items. Before that, people even sent photos via WhatsApp, which compressed them and ruined quality.
I wrote a script that sorted photos into folders by lot number automatically. For the first time, everything was where it should be, saving hours of manual sorting. But there was still a problem: filenames needed a strict format like 6_1.jpg, 6_2.jpg.
Apps Script could rename files but painfully slowly. So I switched to a local batch script. It renamed hundreds of photos in seconds. Suddenly, uploading was faster and cleaner. The only manual task left was choosing the best cover photo.
That small script became Version 2 of our photo workflow, saving hours per auction and supporting six-figure sales. It wasn’t fancy code, but it made a real impact.
What I learned was bigger than just automation:
- Sometimes you don’t just improve a process — you have to rebuild it.
- Real-world automation isn’t about big, complex systems. Tiny scripts can save weeks of work.
- People resist change, but with compromise (like asking them to pick just one cover photo), adoption is possible.
That first script was my turning point. It wasn’t just about code; it was about changing how people work.