Building a Photo Review Tool vs. Buying One
The real cost of building your own client approval workflow, broken down feature by feature.
A minimum-viable photo review tool — upload, per-image comments, one approve button — runs to roughly 108 hours of engineering time before you've added a single feature a client would actually notice missing, like mobile rendering, version history, or a CDN that keeps a 40-image gallery from crawling on someone's phone. That number isn't a guess pulled from nowhere; it's a sum of line items, and you can check the arithmetic yourself in the next section.
The build vs. buy question comes up every time a photographer or a small creative team hits the limits of email, Dropbox, or a shared folder and starts wondering whether it would just be easier to build something themselves. Sometimes it is. Usually the math says otherwise, and the reasons are more specific than "building software is hard." Here's the actual breakdown, what it leaves out, and the handful of situations where building still makes sense.
What "Build Your Own" Actually Means
Before pricing anything, it helps to scope what a photo review tool has to do at minimum. Not a full digital asset manager — just the workflow a client or a teammate needs to look at a set of images and say yes, no, or here's what to change:
- An upload pipeline that handles large files without timing out or losing the connection halfway through
- A resize/thumbnail step so a gallery of 40 high-resolution frames doesn't load as 40 full files
- A shareable, access-controlled link the client can open without creating an account
- Per-image comments, not just one feedback box for the whole gallery
- An approval state for each image (approved, rejected, needs revision) that persists and doesn't rely on someone remembering a verbal decision
- An email notification when the client actually submits their round
That's the floor. It doesn't include version history when a retoucher uploads v2, doesn't include watermarking, doesn't include a mobile-responsive layout that renders correctly on an iPhone in portrait mode, and doesn't include anything for teams with more than one reviewer in the approval chain. Those are all real features that show up within the first few months of actually using a self-built tool — they just don't show up in the initial estimate, which is exactly the problem.
It's worth naming why each of these six items is load-bearing rather than optional. Drop the resize/thumbnail step and a client on a hotel Wi-Fi connection is staring at a spinner instead of photos. Drop per-image comments in favor of one feedback box and you're back to decoding "the third and fifth ones, and also the one with the dog" from a paragraph of prose. Drop persistent approval states and you're relying on someone's memory of a phone call to know which fifteen images out of eighty actually got a yes. None of these are edge cases — they're the first thing that breaks in week two, which is exactly why they belong in the estimate rather than the "nice to have" list.
The Build vs. Buy Math, Line by Line
Here's the line-item estimate for just the floor list above, assuming a developer who already knows the stack and isn't learning image processing or cloud storage APIs from scratch as they go:
| Feature | Estimated hours |
|---|---|
| Upload & storage pipeline | 20 |
| Thumbnailing & CDN delivery | 15 |
| Client-facing gallery + access control | 20 |
| Per-image comment threads | 18 |
| Approval/rejection states + audit log | 12 |
| Email notifications | 8 |
| Mobile-responsive review UI | 15 |
| Total | 108 |
20 + 15 + 20 + 18 + 12 + 8 + 15 = 108 hours. Assume a $100/hour contract rate as a planning figure — adjust it up or down for your market and whether you're paying a contractor or valuing your own time at what you'd otherwise bill for shoots. At $100/hour, that's $10,800 before QA, before the first round of "actually, can it also do X," and before it has handled a single real client gallery under load.
Compare that to the cost of a tool built for this exact job: no development time, live the same day you sign up, and the mobile rendering, CDN, and access control are already solved by people who've been fixing edge cases in them for years.
The Costs That Don't Show Up in the Build Estimate
The 108-hour estimate covers building the thing once. It says nothing about keeping it running. A realistic planning split for the first year after launch — not a measured statistic, just a reasonable allocation to budget against — looks like this:
That's 208 hours in year one, not 108 — and it doesn't include the storage and bandwidth bill, which scales with your shoot volume rather than staying flat. It also doesn't count the cost that's easiest to ignore: every hour spent patching a comment-thread bug is an hour not spent shooting, editing, or finding the next client. For a solo photographer or a three-person studio, that opportunity cost is usually the largest line item on the sheet, even though it never appears on an invoice.
The bug fixes and patches line isn't hypothetical, either. A resize pipeline that worked fine on JPEGs from one camera body can choke the first time a client uploads a HEIC file from an iPhone, or the first time someone opens the gallery in a browser that handles a color profile differently than the one you tested in. Dependency updates aren't optional maintenance you can defer indefinitely — an unpatched library in an upload pipeline that accepts files from strangers is a real security exposure, not a cosmetic issue. And client-driven feature requests tend to arrive exactly when you have the least spare time to act on them: mid-wedding-season, right after someone's tried to use the tool for a 300-image gallery and found the one workflow you didn't build for.
When Building Actually Makes Sense
The math above isn't an argument that building is always wrong. It's an argument for being honest about when it's right, and that's a narrower set of situations than it first appears:
- You already have idle in-house engineering capacity. If a developer on staff has slack time and no other roadmap item, the marginal cost of the 108 hours is much lower than the contractor-rate math above.
- Your approval hierarchy is genuinely unusual. Most studios and teams fit a standard pattern — one client, one decider, maybe a second reviewer. If your workflow involves an approval chain no vendor's data model supports, custom software stops being optional.
- You're building a product to sell, not a tool to use. If the review workflow is your company's product, this isn't a build-vs-buy decision at all — it's the business.
These three cases share a trait worth naming: in each one, the 108-hour estimate isn't competing against a subscription price, it's competing against a cost that's already being paid somewhere else — idle payroll, a workflow no product fits, or a product roadmap that was going to happen regardless. Take any of those away and the comparison reverts to contractor rate versus subscription rate, and the subscription almost always wins on pure economics. Outside of those three cases, the calculus usually favors buying. If what you actually need is lighter than full image review — just a way to track which shoots are approved, edited, and delivered — a general-purpose tool like the ones compared in Notion vs Airtable for photo approval tracking might close the gap without any development at all. And if you're unsure whether the real need is a full asset library or just a review step, it's worth reading through whether you need a DAM or just an approval workflow before scoping a build either way.
What Buying Gets You on Day One
Building it yourself
- 108+ hours before a client sees anything
- You own every bug, forever
- Mobile rendering, CDN, and access control are your problem to solve
- Storage costs and maintenance hours grow with your shoot volume
- Feature requests from clients become your backlog
Buying a purpose-built tool
- Live the same day you sign up
- Security patches and browser fixes ship without your involvement
- Mobile rendering and CDN delivery already solved
- Support is someone else's job, not a side project
- Your hours go to shoots and edits, not maintenance
Tools built specifically for photo approval, Appruva included, exist precisely to absorb that 108-hour list and the 100 hours of upkeep behind it, so the studio doesn't have to carry either.
If you're tempted to build because a vendor's specific feature set doesn't fit, try listing the exact gap first. Often it's one workflow step — not the whole system — and a lighter integration or a manual step closes it for a fraction of 108 hours.
A Quick Decision Framework
Before committing engineering time to a photo review build, run through this checklist. If two or more are true, buying is almost certainly the cheaper path. The value of running it before a build starts, not after, is that every item here is knowable in advance — unlike the bug count or the first client complaint, which only surface once the tool is live and someone is depending on it for a real gallery.
None of this is a case against ever building internal tools. It's a case for running the same line-item math this post ran before starting — because the 108-hour estimate is the cheap part, and the 100 hours after launch is where most self-built review tools actually go to die.
Frequently asked questions
How long does it actually take to build a basic photo approval tool?
Budget around 108 hours for the floor feature set: upload, thumbnailing, a shareable gallery link, per-image comments, approval states, and email notifications. That excludes version history, watermarking, and multi-reviewer support, which typically get added later once the gaps show up in real use.
What's the cheapest way to let clients approve photos without building anything?
A shared folder with a single comment thread is the cheapest option in raw dollars, but it pushes the cost into your admin time instead: chasing feedback, resolving conflicting comments, and manually tracking which images are approved. A purpose-built review tool or even a lightweight tracker like Notion or Airtable usually costs less once that admin time is counted.
Can I just use Notion or Airtable instead of building or buying a review tool?
For tracking status — which shoots are approved, edited, and delivered — yes, a general tool like Notion or Airtable can work. Neither is built for the image review itself: per-image comments, side-by-side version comparison, and approval states tied to a specific frame are workflow needs those tools weren't designed around.
Is it worth building a custom photo review tool for a small studio?
Rarely, based on the math. At an assumed $100/hour rate, 108 hours of initial build plus roughly 100 hours of first-year maintenance runs to nearly $21,000 in either contractor cost or opportunity cost, and that's before storage and bandwidth bills that scale with shoot volume. For a one- to three-person studio, that hour count is almost always better spent shooting and editing.
What ongoing costs come with a self-built photo review tool?
Beyond the initial build, plan for bug fixes and patches, client-driven feature requests, security and dependency updates, and storage or bandwidth costs that grow with your shoot volume. Together these commonly add up to as much time as the original build in the first year alone.