What Actually Changed When I Moved Media Uploads to ImageKit
Storing files myself was never the hard part - serving them fast, at the right size, everywhere, was.
Every upload in this project's admin — a project cover, an artwork gallery image, a blog featured photo — goes through ImageKit rather than sitting on a server I manage myself. The reason wasn't storage. Storage is easy. The reason was everything that happens after storage.
The Upload Is the Easy 90%
Accepting a file, validating its type and size, and saving it somewhere is the straightforward part of media handling. What's harder is making sure the SAME image loads fast on a phone on a slow connection and on a 4K desktop monitor, without hand-rolling multiple resized copies myself. ImageKit handles that transformation on the fly from a single uploaded original, which meant I never had to build or maintain an image-resizing pipeline at all.
One Failure Mode I Had to Design Around
The one piece of real engineering this still required was handling partial failure. An upload has two steps — push the binary to ImageKit, then write the metadata record to Firestore — and those two steps can fail independently. If the Firestore write fails after the file already landed on ImageKit, you're left with an orphaned file nobody can find or manage. The upload flow in this project explicitly rolls back the ImageKit file if the Firestore write afterward fails, so a failed upload fails cleanly instead of leaving invisible debris behind.
Folder Structure as Documentation
The other small decision that paid off: every upload is routed into a predictable folder path based on content type and slug — `portfolio/development/{project-slug}/cover`, `portfolio/art/{artwork-slug}/gallery`, and so on. It's a small thing, but it means I can open the ImageKit media library directly and understand what I'm looking at without cross-referencing the database at all.