I canceled my Adobe subscription this April.
Not as a statement or a hot take. I canceled it because I no longer needed it. The tools I built to replace it had already become the tools I use — every shoot, every edit, every export. Twenty years of Lightroom, and the transition was less dramatic than changing banks.
A few people have asked what the workflow looks like now. Not the philosophy (I've written about that), not the technical architecture (I've written about that too), but the practical, daily, shoot-to-final-image process.
So here it is. One workflow. Five stages. No catalog.
The principle: files are the source of truth
Before the workflow, the principle behind it. Because without the principle, the specific tools don't matter.
In Lightroom, the catalog is the brain. Your ratings, your keywords, your develop settings, your collections — they live in a proprietary SQLite database. The photos on disk are files that the catalog points to. Delete the catalog, lose everything but the photos. Move the catalog to a different machine, break all the paths. Stop paying the subscription, lose write access.
The file-based approach inverts this. The files on disk are the archive. Ratings, keywords, develop settings — everything lives in XMP sidecar files, plain text XML sitting right next to the RAW. Any application can read them. Any application can write them. Delete the application, your metadata stays. Move the files to a different machine, the metadata follows. The database — if there is one — is a cache, rebuilt from the files whenever needed.
This isn't a technical curiosity. It's a design decision about who owns the work. In a catalog model, the application owns it. In a file-based model, you do.
Stage 1: Import and rename
A shoot starts with a memory card. The card has files with names like P4080192.ORF and _DSC4521.ARW. These names are meaningless — sequential counters that reset when the camera does.
The first step is to give the files names that mean something. I use a date-based pattern: 2026-04-08_0192.raw. The date comes from EXIF — the camera's timestamp, not the import date — and the sequence number preserves the shooting order within that day.
The files go into a folder hierarchy by year, month and day: 2026/04/08-Shoot description. This isn't clever. It's just chronological storage. No smart albums, no project folders, no categorization at import. The organization comes later, when I know what the photos actually are.
RAW+JPEG pairs stay together. If the camera recorded both, the renamer keeps them in sync — same base name, different extension. This sounds trivial until you've lost a JPEG orphan in a folder of 800 files.
At the end of this step, I have a folder of cleanly named files in a predictable location. No database has been created. No application state exists. Just files on disk.
Stage 2: Cull
This is the stage most photographers skip, but I'll argue it's an important step.
I came back from a recent trip with 1,200 photos. Probably less than 10% are worth developing. Maybe a couple of handfuls will make it to the final set. The rest aren't necessarily bad — they're just not the ones this time around. If I skip culling and go straight to editing, I'll spend hours developing images I'll never use.
Culling is separate from organizing. It's a fast, binary process: keep or reject. I move through the photos full-screen, one at a time. P (or space) for pick, X for reject. No editing. No zooming to check focus on every shot. First impressions, gut reactions, fast decisions.
The picks and rejects are written to XMP sidecars. Not to a database. The files themselves now carry the information about which ones are worth keeping.
Sometimes I'll rate as well — 3 stars for "good," 4 for "strong," 5 for "this is the shot." Sometimes I'll apply color labels to group related images for a specific use. But the core action is binary: yes or no. Everything else is refinement.
After culling, I delete the rejects. Not move-to-trash. Delete. The card still has the originals if I have a sudden crisis of confidence, but in practice I never go back. The willingness to delete is what makes culling work. If every photo survives, you haven't actually decided anything.
Stage 3: Organize
Now the remaining photos — the picks — need context. Who's in them. Where they were taken. What they're for.
This is where a library tool earns its keep. Point it at the folder structure. It scans the files, reads existing XMP (the pick status from culling is already there), and builds an index. No import. No copying. No "managed library" that moves files into its own folder hierarchy.
Keywords go onto the photos. I'll tag a photo with all keywords I deem relevant, like "Lofoten", "Sunset", "Fishery", "Silhouette" etc. Smart collections pull from these: "all 4+ star photos from Lofoten" is a saved filter, not a manually maintained set.
Keywords, ratings, and labels are written to XMP sidecars. The same sidecars that already carry the pick status from culling. They accumulate — each stage adding its layer of metadata without overwriting what came before.
The library tool doesn't store this information exclusively. It caches it for fast search, but the authority is the sidecar file. Blow away the database, rescan the folder, and every keyword is still there. This matters when you have tens of thousands, if not hundreds of thousands of photos and decades of metadata.
Stage 4: Develop
Now the creative work. The photos are culled, organized, and ready for processing.
I open the RAW file in the develop tool. Every adjustment is just a number — "Highlights: -40," "Vibrance: +15" — stored as parametric instructions, not pixel edits. And yes — you guessed it — the adjustments are saved to an XMP sidecar. The same sidecar that carries the pick status and the keywords. A sidecar for a well-traveled photo might contain: a 4-star rating from culling, 12 keywords from organization, a full set of develop instructions, and a crop.
The develop tool doesn't need to know about the keywords. The library doesn't need to know about the develop settings (though it still does, through the XMP). Each app reads what it understands and preserves everything else. The sidecar is the connective tissue.
One thing that feels different from Lightroom: because the develop tool is only a develop tool, there's no temptation to organize from within it. No collections panel. No keyword sidebar. You're here to edit, and the UI reflects that. When the develop work is done, you leave (and do the organizing in the library app if warranted).
Stage 5: Export
The RAW file hasn't been touched. Every creative decision lives in the sidecar. Export renders the final image: applies all 25 pipeline stages at full resolution and writes a JPEG or TIFF.
The export is disposable. Change a develop setting, re-export. The RAW and the sidecar are the archive; the JPEG is a rendering. This is no different from Lightroom — non-destructive editing is the same principle. The difference is where the instructions live. In Lightroom, inside a catalog. Here, in a text file you can open in any editor.
What the XMP sidecar actually looks like
People talk about XMP as if it's exotic. It's XML. Here's a simplified version of what one looks like after a photo has been through the full workflow:
<x:xmpmeta>
<rdf:RDF>
<rdf:Description
xmp:Rating="4"
xmp:Label="Blue"
crs:Exposure2012="+0.65"
crs:Contrast2012="+18"
crs:Highlights2012="-40"
crs:Shadows2012="+25"
crs:Vibrance="+15"
crs:CropTop="0.042"
crs:CropLeft="0.083"
crs:CropBottom="0.958"
crs:CropRight="0.917">
<dc:subject>
<rdf:Bag>
<rdf:li>Lofoten</rdf:li>
<rdf:li>Norway</rdf:li>
<rdf:li>landscape</rdf:li>
</rdf:Bag>
</dc:subject>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>Rating, label, develop settings, crop, keywords — all in one file. Human-readable. Portable. No application required to understand it.
This is the file that makes everything work. It's what lets you swap any tool in the chain without losing what the others wrote. It's what lets you abandon the entire workflow and move to Capture One or Darktable tomorrow, and your ratings and keywords come with you. It's what makes the files the source of truth instead of the application.
A note on XMP and compatibility
Two things worth being honest about.
First: Lightroom can write to XMP. You can enable "Automatically write changes into XMP" in the catalog settings, and it will write ratings, keywords, and develop settings to sidecar files. You can also convert your RAWs to DNG, Adobe's open archival format, which embeds XMP metadata inside the file itself. So the file-based approach isn't impossible within Lightroom — it's just not the default, and the catalog still remains the primary source of truth. (DNG has its own complications: it modifies the original file, which complicates backup strategies, and not all software handles DNG identically. I prefer sidecars next to untouched RAWs.)
Second: XMP portability has real limits when it comes to develop settings. Ratings, keywords, pick status, color labels — these are standardized and transfer perfectly between any tool. But the develop instructions — exposure, contrast, color grading, local adjustments — are proprietary to each application's processing engine. Lightroom's crs:Highlights2012="-40" and Photo Developer's highlight adjustment both live in human-readable XMP, but they don't produce identical results. Each app has its own rendering pipeline, its own tone curves, its own interpretation of what "-40 highlights" means.
What XMP gives you isn't pixel-perfect transfer of develop settings between tools. What it gives you is a human-readable reference. If you switch from Lightroom to Photo Developer — or the other way around — you can open the sidecar, see exactly what the previous tool did ("Exposure +0.65, Highlights -40, Vibrance +15"), and recreate the intent in the new tool. It's a translation guide, not an automatic translation. Your ratings and keywords, though, come across perfectly — and for most photographers, that's the metadata that took years to build.
Anything missing?
Honestly less than I expected.
Cloud sync. My photos don't sync to Adobe's servers. I don't edit on my phone. I back up to an external drive using rsync, which is less elegant and more reliable. For me this is a non-issue; for someone who edits on an iPad, it's a dealbreaker.
The ecosystem. Thousands of community presets. Deep Photoshop integration. A plugin architecture. I have a handful of built-in presets that I actually use and the ability to build my own. (And the Smart Develop is really good, so often I more or less one-press the develop.)
Face recognition. Lightroom's face detection is genuinely useful for family photo organization. I don't have it. I use keywords instead, which is slower and requires discipline. For a wedding photographer, this might matter. For me, it doesn't.
A single application. The workflow uses multiple specialized tools instead of one monolithic one. This means switching between apps. For some people, that's friction. For me, it's clarity — each context has its own space, its own shortcuts, its own purpose. I don't organize from the develop tool. I don't edit from the library. The boundaries help.
What I gained
Ownership. Every piece of metadata I've created in twenty years of photography is now in a format I can read with a text editor. No subscription required to access my own creative decisions.
Speed. A dedicated culling tool is faster than Lightroom's Library module because that's all it does. A dedicated RAW developer with GPU-native shaders feels more responsive than Lightroom's Develop module on the same hardware. Specialization matters.
Predictability. The develop pipeline is deterministic. Same settings, same image, same result. No adaptive processing. No AI second-guessing. When I move Highlights to -40, I know exactly what that means because it means the same thing on every photo.
Replaceability. If a better culling tool appears tomorrow, I can switch to it. If a better RAW developer appears, I can switch to that too. My metadata isn't locked inside any of these apps. The XMP sidecars work with anything that reads the format — which is everything: Lightroom, Capture One, Darktable, Photo Mechanic, ExifTool.
And by the way, I built my own web gallery as well, that beats Lightroom's web gallery in every way imaginable.
Is this for you?
Maybe. Depends on what you value.
If you want one application that does everything — import, cull, organize, develop, export, sync, print — and you're comfortable with a subscription, Lightroom is still excellent software. I used it for twenty years and I'm not pretending otherwise.
If you value file-level ownership, if the idea of a proprietary catalog makes you uncomfortable, if you prefer specialized tools that each do one thing well, if you want to pay once and not think about it again — then a file-based workflow is worth considering.
The tools exist. The format (XMP) is open. The workflow is real — I've been using it daily for months, on real shoots. It works.
It just works differently. And for me, differently turned out to be better.
The tools mentioned in this post are part of the Photo Suite — a collection of focused apps for the complete photography workflow on macOS. Photo Developer and Photo Culler are available on the Mac App Store. No subscription.