FotoAlpha Case Study: Claude-Run Engineering for a Photography Platform
· Ashwin Das
At a glance
True Tech Professionals used Claude as the planning, architecture and audit layer of a full engineering team to add verified original-photo retrieval to FotoAlpha, a photography platform. In the live end-to-end test, the desktop app fetched and verified 2,000 original photographs (41 GB) in 87.7 seconds, with every file correct and no memory growth.
| Client | FotoAlpha, a photography software platform for photographers (web, desktop and mobile apps, one backend) |
|---|---|
| Engagement | Fixed-scope delivery: stamp every uploaded photo with a fingerprint, then let the photographer fetch the exact originals for an accepted print order |
| Ownership | FotoAlpha owns the system and its code. True Tech Professionals built it as the developer. |
| How Claude was used | Claude planned the architecture, wrote every design and test specification, ruled on every disagreement, and ran an independent hostile code review before each change was allowed in |
| Platform | Electron desktop app for Mac, React front ends, Node.js backend |
| Headline result | 2,000 photographs, 41 GB, fetched and verified in 87.7 seconds; zero wrong files; no slowdown over the run |
Note on scope: Claude ran the engineering process for this project; the FotoAlpha product itself does not call Claude.
The client and the problem
Photographers upload event photos to FotoAlpha; customers then order prints. When a print order is accepted, the photographer needs the exact original file, not a compressed copy, and finding it by hand across thousands of photos is slow and error-prone.
The codebase made this harder. It has three separate React front ends (web, desktop and mobile) that had grown apart over time, one shared backend, and no automated tests covering the desktop upload engine. The client has a small in-house team focused on interface changes, so True Tech owned all engineering and every production release.
The agreed scope was two stages:
- Stage 1: give every photo uploaded from the desktop app a fingerprint of its original bytes.
- Stage 2: when a print order is accepted, let the photographer fetch the exact originals into a folder of their choice, with every file checked against its fingerprint.
How Claude ran the engineering
True Tech gave Claude the seats where judgement matters and kept a second AI vendor’s coding agent as the builder, so code is never reviewed by the model family that wrote it.
- ChairmanClaude Fable 5 · plans and decides
- ArchitectClaude Opus 5.5 · writes specs, tests
- CoderCodex · writes the code
- Hostile auditfresh Claude session · hunts for defects
- Any defect? Yes: the coder fixes it. If the coder disagrees with a finding, the chairman decides.
- ↓ no critical defectsFounder releasesin his own terminal
A change moves left to right; any defect sends it back to the coder, and only a clean audit reaches the founder, who runs every git command, build and deployment himself.
What was delivered
Stage 2 was built as five small pieces, each designed, built, audited and committed on its own, plus one fix to existing code found along the way.
| Piece | What it does |
|---|---|
| Test runner and safety guard | Lets the desktop app’s main process be tested, and blocks any test from reaching the network or production storage |
| Retrieval engine | Downloads each original into a private staging folder, checks its fingerprint, copies it into place once, then reads it back to confirm |
| Connection to the app | Wires the engine into the desktop app so the screen can start a fetch safely |
| Photographer’s screen | A “Fetch original photos” button on accepted orders, plain-language results, and a warning before an order leaves “Accepted” |
| Scale test | A frozen measurement of 2,000 photographs on real hardware, judged against rules written before the run |
| Upload engine fix | A race condition in how upload chunks were cancelled, found by the audit and fixed |
On the server, a new route returns the list of originals for an accepted print order. The desktop installer was built for Mac and notarized by Apple.
Measured results
Every pass/fail limit below was written down and fingerprinted before the test ran, so the result could not be bent to fit the numbers afterwards.
| Measure | Rule set in advance | Result |
|---|---|---|
| Photographs fetched in the live test | All 2,000 correct | 2,000 of 2,000 correct, sizes matching the plan; 25 random files re-fingerprinted, all matched |
| Time for 2,000 photographs (41 GB), live app | Recorded, not judged | 87.7 seconds |
| Time for 2,000 photographs, retrieval engine alone | Recorded, not judged | About 2 minutes 47 seconds, four repeated runs |
| Slowdown from first 500 to last 500 photographs | Under +21.6 milliseconds per photo | −0.24 and −0.03 milliseconds (no slowdown) |
| Memory growth over the live run | Under 50 MB | −1.4 MB (flat) |
| Repeat fetch of an already-fetched order | Nothing copied twice | 2,000 already there, 0 copied again, 69.6 seconds |
| Network calls to production during the live test | Zero | Zero; the test ran with the Mac offline, proven three times |
The client did not want a speed target, so time was recorded but never used to pass or fail the work.
What the process caught before it reached the client
The value of the Claude-led review was in what it stopped, not only in what it built.
- A race condition in existing upload code. The hostile review of the test runner found that cancelling an upload could let pieces of a file keep travelling. It was fixed with six new tests.
- A wrong message for older photos. Before any code was written, Claude found that photos uploaded without an original filename would make a successful fetch look like a failure. The specification was corrected and the photographer now sees “Photo 3” instead.
- A test that could never fail. A review found one keyboard-focus test that passed no matter what the code did. It was rewritten and a new check proves it now fails when it should.
- Production addresses inside the installer. Before the build, every web address baked into the installer was listed and compared with the previous release, so no test or development address could ship.
- A production server that had drifted. Just before delivery, a check of the live server showed it had been updated separately from our code. Delivery was paused rather than shipping an app whose server half was missing, and the two were brought back into one reviewed change before release.
No piece reached the client until the final review returned the verdict “NO CRITICAL DEFECTS FOUND”.
Lessons and what True Tech brings to Claude clients
The lesson from FotoAlpha is that Claude is most valuable when it is given the roles where judgement matters: design, review and final decisions.
- Separate the maker from the checker. The model that writes code never reviews it; reviews come from a different model family with a fresh session.
- Write the pass/fail rules first. Audit criteria and test limits are fingerprinted before the work exists, so nobody can move the goalposts.
- Keep a human on every risky step. Every git command, build and deployment runs in the founder’s own terminal, never by an agent.
- One source of truth. A single status document holds the current state, so any new session starts from facts, not memory.
True Tech Professionals, founded in 2019 in Panchkula, India, is an AI-native product studio. Using this workflow, the team has shipped more than seven products to production since mid-2025. Contact: info@truetechpro.io, truetechpro.io.