Computer vision

Vision projects succeed or fail on capture conditions, and most of the risk sits outside the model. Glare on a laminated label, a camera mounted slightly too high, an object photographed against a background it was never trained on, a lens that fogs in a cold store — each of these does more damage than any architecture choice. The first useful piece of work on a vision project is usually not modelling; it is collecting a few hundred images from the real environment and discovering what the model will actually be looking at.

Document and receipt extraction is the most common request and has its own trap: the accuracy that matters is per-document, not per-field. A model that gets 98% of fields right sounds excellent until you notice that means most documents contain an error somewhere, and a human has to check all of them anyway. Designing for that reality — confidence scores, targeted review of the uncertain fields, and a correction path that feeds back — is worth more than chasing another point of raw accuracy.

Where the inference runs is an early architectural decision with real consequences. On-device is private, works without a connection and has no per-image cost, but constrains model size and drains a battery. Server-side is more capable and easier to update, and it means every frame is bandwidth you pay for and latency the user waits through. For anything involving a live camera, that latency budget usually decides the answer before anything else does.