We had a collection of old drives and a familiar problem: duplicates, inconsistent folder names, different versions of the same report and no reliable inventory.

We built an internal tool to help examine the archive. It is not a member product and there is no promise of a download or support service. The objective was to identify duplicates and produce an inventory without allowing a script to destroy source files.

The build was not a single successful prompt. We had failed attempts and changes that broke working behaviour. We learned to make one change at a time, test on synthetic files before touching real archives and have another model independently inspect the proposed changes. Codex did implementation work; Claude was used for verification. Neither replaces a proper test.

A useful test creates fake folders containing identical files, near-duplicates and different documents with the same name. The tool should report what it found and leave the originals alone. Deletion is a separate human decision, and only after a consolidated copy has been backed up and restore-tested.

There is also a privacy lesson. Debugging can expose file paths, folder names or scan logs even when client document contents are never uploaded. Do not make absolute claims that no information left the machine unless the logs support them.

This is how we build software without being professional programmers: small changes, test data, independent review and a recovery point. It is slower than the demonstrations suggest and cheaper than losing an archive.