Drive was already the storage system. The app had to make the handoff reliable.
The app gives each device a shot list, uploads the files while the technician reviews extracted specs, and finalizes one named Drive folder.
separate capture modes
Computer, mobile device, and general upload
app upload limit
Oversized video gets a specific fallback
staged folder carried through finalization
Retries do not create a new folder
AI-written make or model anchors
The technician enters those fields
A folder full of pictures can still be missing the one picture the listing needs.
Photos used to depend on memory: get the hero image, the ports, the label, any damage, the specs screen, and whatever else matters for that device. Missing one of those is usually discovered later, when the item has moved and somebody starts the listing.
The app replaces memory with a shot list. Computer Inventory, Mobile Device Inventory, and General Upload are separate modes because they do different jobs. A powered-off phone should not require a settings screen. A cellular phone should require carrier-lock evidence. A booting computer should have a specs path.
Upload runs while the technician reviews what the app extracted.
Computer mode begins with make, model, platform, laptop or desktop, boot state, installed storage, and the specs-capture choice. The technician enters those fields, and the model cannot overwrite them.
Confirm Specs creates a temporary Drive folder and a server-issued upload session. The media begins uploading. Relevant evidence photos are sent for structured extraction, and the review dialog shows both upload progress and the extracted fields.
Each field shows where it came from, its confidence, and the source photo. The interface can label a value OCR, Review, Corrected, Fallback, or Manual. The technician can correct every field and record the physical condition before finalization.
- 01
Choose a mode
Computer, mobile, and general upload have different evidence rules and separate local drafts.
- 02
Enter the anchor fields
Make, model, device state, and capabilities tell the app which evidence is possible and required.
- 03
Capture the shot list
The cards cover listing image, specs, ports, condition, labels, damage, inside views, and optional video as applicable.
- 04
Upload and review together
Files move to the staged folder while the technician checks extracted values and their source photos.
- 05
Finalize the folder
The same staged folder is renamed to make, model, and identifier. It receives human-readable filenames, metadata.json, and optional notes.
Technician feedback changed the evidence model.
I first treated mobile as a variation inside Computer Inventory. That hid decisions that matter for phones and tablets, so Mobile Device Inventory became a top-level mode.
The current choices cover Apple or Android, phone, tablet, media player, and other devices. Cellular capability adds carrier-lock evidence. Battery-health availability adds a battery screen. Device Info is required when accessible. A sticker or serial photo remains required even when the device does not boot.
The iOS camera path also moved back to the native file input after a custom browser camera caused cropping, orientation, transition, and EXIF problems. The “better” camera UI was worse on the device technicians were using.
A partial upload used to look like a total failure.
An oversized video or a later-file error could happen after several photos had already reached Drive. The first interface said the upload failed. A technician could retry and create duplicate folders or upload the same files again.
Now the screen shows how many files reached Drive, which file failed, and which filenames were confirmed. Retry stays in the same folder and skips confirmed files. The operator can open the Drive folder. A video over 100 MB gets a direct instruction: finish the app upload, then add the video manually in Drive.
Restored iPhone drafts created folders and then failed on the first photo.
In one production incident, the first four uploads worked. Later attempts created the staging folder but sent no photo. Google access was fine.
The failure came from restoring the saved image through fetch(data:). iOS WebKit returned Load failed. Converting the data URL directly to a blob in chunks fixed the problem.
That incident is why local draft recovery and upload recovery are separate concerns. A draft can be present and still be reconstructed incorrectly.
The app removes repeated naming, waiting, and blind retries. I have not timed the full handoff.
The technician no longer creates the folder, renames every image, types visible specs twice, waits for upload before reviewing, or restarts the entire item after a partial failure. The next system receives one folder with predictable names and structured metadata.
There is no measured baseline for technician minutes, retake rate, duplicate-folder rate, or correction time. I am describing the removed work without converting it into a fake percentage.
Here is what remains unmeasured or unresolved.
- Google authorization and approved-folder access still have to be current.
- Files above 100 MB cannot use the app upload path.
- Large video on a slow connection can still require manual Drive upload.
- AI extraction can time out, return invalid data, or omit a field; human review remains required.
- Browser drafts stay on the device where they were created.
- Current correction rate, upload failure rate, weekly volume, time saved, and model cost are unknown.