Archive note, June 2026: This post is based on Markit image-pipeline and user-manual notes.
The glamorous part of Markit is the AI appraisal idea.
Take photos of an object, identify what it might be, gather evidence, estimate value, and generate listing drafts for marketplaces. That is the part people notice.
The less glamorous part is more important: getting the photos into the system without making the workflow miserable.
Intake is where the real world meets the code.
Cameras Do Not Care About Your Web App
A marketplace research tool has to accept that photos come from different places.
Sometimes the object is photographed with a real camera. Sometimes the only practical option is a phone in the field. Sometimes photos are already sitting in a desktop folder. Sometimes they arrive through iCloud, Dropbox, Google Drive, Syncthing, or another sync layer.
That means one upload button is not enough.
Markit was designed around several intake paths:
- Desktop upload.
- Drag and drop.
- Batch file selection.
- Folder intake from a local directory.
- Optional synced-folder intake.
- Mobile browser intake when the app is reachable from the phone.
The goal was not elegance for its own sake. The goal was reducing friction at the exact point where friction kills use.
Preserve The Original
Every image in Markit is evidence.
That changed the pipeline design. Storage efficiency matters, but the original upload still needs to survive. A compressed display image may be good enough for the browser, but a future OCR pass, AI model, or human review may need the untouched file.
The pipeline stores a small bundle:
- Original upload.
- WebP display derivative.
- WebP thumbnail.
- Metadata.
- SHA-256 checksum.
The display derivative keeps the UI fast. The thumbnail keeps browsing manageable. The checksum helps detect duplicate uploads. The original remains available for audit.
That is a different priority order than a simple web gallery.
Batch Uploads Need Partial Success
Real batches are messy.
One image may be valid. Another may be corrupt. A third may be the wrong format. If the whole batch fails because one file is bad, the user has to repeat work for no good reason.
Markit uses partial success. Valid JPEG, PNG, and WebP files are preserved and processed. Invalid files are skipped. The item page reports what happened.
That is a small implementation detail with a large usability effect. It respects the reality that intake is often done quickly, from mixed sources, with imperfect files.
The Network Constraint
Phone intake exposed an important architecture constraint: a phone cannot reach an app bound only to 127.0.0.1 on a desktop.
That forced the project to separate the idea of mobile intake from the local development topology. The phone workflow can exist, but it needs a LAN-visible host or a hosted server. Until then, synced-folder intake may be more practical.
That is the kind of lesson that only appears when the workflow touches the physical world.
The AI appraisal layer may eventually be impressive. But the project will succeed or fail earlier than that, at the moment a photo needs to move from a camera or phone into a durable research record.