Why I started LightPhotos

What I learned

• Keep your photos as plain files. A backup only helps if something can still open it. Ordinary files on a drive can be opened by pretty much any app, now or ten years from now.
• Buying software once doesn't mean you'll always be able to use it. A macOS upgrade stopped my Lightroom license working just as completely as cancelling a subscription would have, and nothing warned me first.
• More features made the free editors harder for me. They could do everything, and that's why I couldn't get started with them.
• Write the list before the code. Writing down what the first version had to do is what let me keep saying no to everything else.

Nothing quite fit

I'm an amateur photographer, and I like taking pictures with my Sony full-frame camera. I shoot RAW, which means the camera saves the unprocessed sensor data, so most of my shots need a little work before I can share them.

I really do like Apple Photos. It looks great, it's fast, and it does nearly everything I wanted. If you use it and you're happy, I completely understand why.

There's one deal breaker for me, though, and it's a big one. Your whole library lives in a single file, in a format only Apple Photos can read. I found out what that means the hard way. A newer version of macOS refused to open the Photos libraries on my older backups, and several years of pictures went with them. If you've ever lost photos to an upgrade, you know how sick that feels.

I can't get past that. The features and the speed are fine, but all of it depends on a format I don't control, and I'm not willing to take that risk again.

A single library doesn't fit how I keep things either. My main drive is for recent work, and older shoots move off to other drives. I don't want hundreds of gigabytes sitting on my laptop's main drive, locked inside a library I might not be able to open in a few years.

So I built one

That afternoon I sat down to write a basic version myself. I wasn't trying to clone Lightroom. I wanted the smallest thing that would get these photos to my friends, so I wrote the list down before I wrote any code.

1. Open any folder and show the photos in it. My photos stay as ordinary files on whatever drive holds them, so I can always open them with something else.
2. Rate photos from 1 to 5, so I can go through a shoot quickly and mark the keepers.
3. Filter by rating, so I only see and work on the photos I like.
4. Adjust exposure, highlights, shadows and the other basics.
5. Keep every adjustment non-destructive. The original file is never touched, so I can always undo an edit or start over.
6. Export selected photos to JPEG, ready to send.
7. Run on a Mac.

That's all it had to do. Anything that wasn't on the list stayed out of the first version, and having it written down is what helped me keep saying no.

What else I'm trying to learn

I try to write very little of the code myself and let coding agents do most of it. That sounds simple, but doing it well is hard. An agent will happily hand you something that compiles and runs, but gives the wrong result some of the time or crashes in a case nobody tested. A photo editor shows those problems quickly. If a slider lags, or a folder of RAW files uses up all your memory, you notice right away.

So LightPhotos is two projects for me at once. It's the photo editor I wanted, and it's how I'm figuring out what it takes to build software with agents while still caring about quality and speed. That's mostly what these posts are about.

What comes next

In the next post I'll walk through the big design choices behind LightPhotos and what I gave up for each one. If any of this sounds familiar, I'd really like to hear how you dealt with it.