The 5-tool proofing zoo photographers actually pay for (and what to use instead)
A working wedding or event photographer doesn''t have a cloud storage problem. They have a vendor problem — four to six paid tools just to deliver one shoot. The fix isn''t picking a better one. It''s collapsing the parts of the stack that are secretly the same job.
The five tools you actually pay for
Ask a full-time wedding or commercial photographer what they use to deliver a shoot and the list is startlingly consistent. The proofing gallery is rarely one tool — it is five, and they each bill monthly.
| Tool | Job | Typical annual cost |
|---|---|---|
| Pixieset or PicTime | Branded client gallery | $228–$360 |
| ShootProof or Zenfolio | Proofing, favourites, contracts | $180–$300 |
| HoneyBook or Dubsado | Contracts + invoicing | $204–$360 |
| Backblaze or B2 | Off-site backup of source files | $99–$120 |
| Lightroom + Photoshop | Edit + cull | $240 |
The list goes on — Pic-Time''s add-on video gallery, a Smiler review-collection subscription, a Filestage seat for client approvals on the design side — but five is the floor. Most working photographers we have asked run four to six paid tools per shoot and rarely feel any single one is overpriced. The frustration is structural: each tool owns one slice of a delivery that should be one workflow.
What each one does well
None of these are bad products. They are each strong at their narrow job:
- Pixieset prints beautiful, branded galleries. Clients love the experience.
- ShootProof handles proofing and favourites cleanly and ties them to a contract status.
- HoneyBook is the de facto CRM for solo creators and is genuinely good at the contract-to-invoice loop.
- Backblaze B2 is a low-cost object store that does exactly what object stores should.
- Lightroom is the editing standard for a reason.
The product quality is not the problem. The architecture is. Three of the five — the gallery, the backup, and the cloud where the masters live — are all doing variations of the same job: store bytes, hand them to a viewer. Splitting them across three vendors is a 2018 constraint, not a 2026 one.
The hidden cost: 5 tools, 5 logins, 5 invoices
Run the real numbers on a working photographer doing 30 shoots a year:
- Gallery + proofing: $360 + $240 = $600
- CRM + contracts: $300
- Backup of source files: $120
- Lightroom + a single NiceToHave plugin: $300
- Annual total: ≈ $1,320/yr, paid in 12 monthly withdrawals to 5 different vendors, on 5 different renewal dates, with 5 different cancellation policies.
Now the time cost, which is the part that does not show up on the credit card statement:
- 15 minutes per shoot to upload final selects to the gallery tool
- 10 minutes to build the contract, send for signature, and tag the gallery against the contract
- 10 minutes to copy the source files into the backup bucket and verify the upload completed
- 5 minutes to chase a client who saw the gallery but didn''t sign the contract, and another 5 to remind them to mark favourites
- ≈ 45 minutes per shoot of glue work that none of the tools does for you
Over 30 shoots a year that is 22.5 hours of billing-zero overhead — paid time spent keeping five tools talking to each other. The gallery-upload step alone accounts for a third of that, because every tool wants its own copy of the same JPEGs.
The unification: a proofing gallery that lives in the same place as your source files
The stack exists because, historically, the gallery tool, the backup tool, and the file store were three different products. The gallery needs web URLs and a viewer; the file store needs terabytes; the backup needs versioning and immutability. Splitting them was the only option when "the cloud" was a single provider and "the gallery" was a WordPress plugin.
That is no longer true. If the gallery, the backup, and the cloud-to-cloud transfer all read from the same set of providers you already store your masters in — Google Drive, Dropbox, OneDrive, B2, S3 — the proofing layer stops being a separate vendor. It becomes a view onto the files you already have, and the backup and the transfer stop being two more subscriptions on top.
This is the model Whimsy was built around. You connect the clouds you already pay for. You select a folder of final selects. Whimsy generates a branded, expiring proofing link from those exact files — no upload, no copy, no second store to keep in sync. The client marks favourites, the favourites are written back to the same folder, and the source files keep living in the cloud you control.
The "we never see your files" promise matters most here: a proofing link that points at the originals, not at a copy, is the only way to be sure the gallery the client saw is the same as the deliverable you archived.
What Whimsy owns in this stack
The honest accounting is more than the gallery. Three of the five line items in the proofing-zoo stack are secretly the same job — and Whimsy does all three of them.
- The proofing gallery (replaces Pixieset / PicTime / ShootProof for the gallery step). Branded, expiring, no second copy of the files.
- The cloud-to-cloud transfer (replaces the rclone scripts, the MultCloud subscription, the "I will move this when I have a weekend" promise). Whimsy''s transfer engine uses rclone as the workhorse and a browser-direct fast path when you are logged into both endpoints — same machine, no server hop, no egress double-charge. Checksum verification on completion, conflict policies on the destination, no silent overwrites. We have written about the consolidation workflow for the photographers sitting on 6 TB split across two providers who just want it in one place.
- The backup of the masters (replaces Backblaze B2 or Wasabi for the photographers who already pay for S3, and replaces "I hope I never need to restore this" for the ones who don''t). Whimsy runs Kopia against an AWS S3 destination you control, with bucket versioning and Object Lock — compliance or governance mode — provable by a one-time immutability probe before any backup is accepted. Credentials are STS-scoped per job (write / restore / maintenance), every issuance is logged, and TTLs are bounded. Restore has three delivery modes (back to the connector, direct download, or ship a drive), and Whimsy schedules a periodic test-restore so the backup is not just a belief. A real backup is not a sync — and the implementation agrees with the slogan.
- The post-delivery review, testimonial, and public-review redirect (replaces the follow-up email, the second product, and the "I keep forgetting to ask for a Google review" problem). The same delivery link collects a private review (comment / approve / request changes), an internal testimonial once the client has approved or downloaded, and a redirect to your Google Business / Facebook / custom review page. We have written the post-delivery playbook for the part of the workflow that happens after the client closes the gallery.
That is the part of the stack Whimsy collapses: gallery, transfer, backup — three vendors, one engine, the same cloud you already pay for.
What this doesn''t solve (honestly)
The remaining two line items are real products doing real work, and Whimsy is not in those businesses.
- HoneyBook is still the CRM. Contracts, invoices, and payment reminders live there for a reason. Whimsy does not own that loop and is not going to.
- Editing is still Lightroom. We are not building a DAM or a non-destructive editor. The cull and the edit happen upstream of the gallery.
Two products, not five. The proofing-zoo was five subscriptions because the storage layer was split into three. Fix the storage layer and the rest of the stack follows.
A realistic stack for a working photographer today
A sensible Whimsy-first stack for a working wedding or commercial studio in 2026:
- Whimsy for the branded proofing gallery, the cross-cloud transfer, and the object-locked backup of the masters
- HoneyBook or Dubsado for contracts and invoicing (we are not in this business)
- Lightroom for editing (the standard for a reason)
Annual cost: ≈ $540/yr, three vendors, three renewals. The gallery, the backup, and the cross-cloud transfer now share one engine, one set of credentials, and one place to check when a client says "I can''t see my photos."
The proofing-zoo was a real solution to a real problem in 2018. In 2026, the gallery, the backup, and the cloud-to-cloud transfer do not have to be three separate products from three separate vendors — and that is the part of the stack worth simplifying first.
Whimsy is in free early access at whimsy.numeracode.com. Connect the clouds you already pay for, generate a branded proofing link from a folder of final selects, schedule an object-locked backup of the masters, and stop paying a second vendor to host a copy of files you already own.
Related Educational Resources
Enhance your learning with these complementary resources
Comments (0)
The views in comments are those of the author and do not necessarily reflect the views of Numera. We reserve the right to remove inappropriate content.