Why do photos not arrive from the field?

Because they leave full size, several megabytes, over a network that cuts out, and an interrupted upload restarts from the beginning or is lost. The construction that settles this: reduction on the device before any upload, offline queue, resumable chunked upload that resumes at the chunk after a cut, and a visible state for the agent.

Should the full-size original be kept?

Only if the trade requires it, an expert assessment or a zoom on a detail for example, and that is written in the first week. For most proof files, a 1,600-pixel-wide photo is enough to read a plate, a meter or a defect, and weighs twenty times less. If the original is kept, it leaves after the reduced version, when the network allows.

How do you prove a photo was not retouched?

With a SHA-256 fingerprint computed on the device at capture, checked by the server at receipt, and recomputable at any time on the stored object; a modified image gives a different fingerprint. The object is versioned and never rewritten. That shows the stored image is the one that was taken; the legal weight depends on context.

Why two times on every photo?

Because the phone's time is declared and editable by whoever sets it, and the server's time is received and not editable. Both are kept; a gap of a few minutes is a network cut, a gap of several days calls for an explanation, and the record makes it visible instead of hiding it.

Where do you store thousands of photos?

In versioned object storage, not in the database: the database keeps the record, storage keeps the bytes, and every write creates a version. Photos are served through signed links that expire, never through a public URL. The choice of hosting location, Algeria or Europe, follows the dedicated guide.

Can photos already taken on WhatsApp be taken over?

Yes, as imported photos, marked as such, with the file date and no fingerprint at capture; they are linked to the file but the record says they were not taken in the application. You do not pretend.

How long does it take to set this up?

Six weeks in the typical calendar: one to write the rules, one for capture and reduction, one for queue and upload, one for storage and record, one for access and export, one for retention and measurement. The duration depends on the number of file types and whether a field application already exists.

“The photo never arrived”: what gets built so that site, delivery and inspection photos hold up in your application in Algeria in 2027, capture, compression, resumable upload, object storage, fingerprint, signed access

Short answer. A proof photo is taken in the application, not in the gallery, on an enrolled device by a logged-in author. It is reduced on the device, to 1,600 pixels and WebP, before any upload: from a few megabytes to a few hundred kilobytes. On the device it receives its SHA-256 fingerprint, the device time, the position and its accuracy, the file and the author. It waits for network in the offline queue, leaves in chunks with a resumable upload protocol, and resumes at the chunk after a cut. The server notes its own time, recomputes the fingerprint, refuses if it differs, writes the object into versioned object storage, produces thumbnails and links the record to the file. Access is through a signed link that expires, and you know who saw it. The full-size original is kept only if the trade requires it, and retention is written. Six weeks, the first without code.

This guide is for the manager of a delivery, works, installation or rental company whose photos serve as proof, the founder settled in France who must be able to look at a site or an inspection remotely and trust it, and the person who has seen a photo disputed for lack of a reliable time. It does not repeat how an application works without network, described in the offline guide, nor how object storage is backed up, described in the backups guide; it describes what gets built around the photo itself, and it extends our software engineering page.

Photos that hold up, in five layers

A photo that proves something crosses five layers, and the second, on the device, is the one home-made applications forget.

Figure 1 · The accented layer is what changes everything on a weak network: the photo is reduced and fingerprinted on the device, before any upload. Applications that send the original and reduce on the server lose photos at every cut and cannot prove that what arrived is what was taken.

Capture. Shooting happens in the application, with an expected frame, a number of photos per file, managed flash, and no cropping; the device is enrolled and the author logged in by code, following the roles and audit log guide. The photo is born in the file, never in the gallery. On-device processing. Reduction to 1,600 pixels wide and conversion to WebP before any upload; SHA-256 fingerprint; device time, position and accuracy, file and author attached. This is the accented layer: what leaves weighs twenty times less and already carries its proof. Transport. Offline queue in the local database, resumable chunked upload with an open protocol, resume at the chunk after a cut, acknowledgement per chunk; a photo is never resent from the start.

Storage. The server notes its own time at receipt, recomputes the fingerprint and refuses if it differs; the object is written into versioned object storage, thumbnails are produced, and the record is linked to the file and the author; the database keeps the record, object storage keeps the bytes. Access and retention. Signed link expiring in fifteen minutes, access log, export with fingerprints for a dispute, written retention then logged deletion; the photo is never public. Where those bytes live, in Algeria or in Europe, is a separate decision, described in the hosting guide.

One photo, from the camera to the file

The figure follows a single photo and what it weighs at each step. Everything that matters happens before it leaves the phone.

Figure 2 · One photo, from capture to file. It goes from 4.2 MB to 240 KB on the device, receives its fingerprint and metadata, waits for network in the offline queue, leaves in three chunks of which the second is resumed after a cut, and arrives seven minutes later with its fingerprint checked. Two times are kept, the device’s and the server’s. Sizes and durations are a constructed example.

Captured at 12 megapixels, the photo weighs 4.2 MB; reduced to 1,600 pixels wide and converted to WebP on the device, it weighs 240 KB, enough to read a plate, a meter or a tiling defect, and twenty times less to send over a network that cuts out. It receives its fingerprint and metadata, waits in the offline queue while the network is down, then leaves in three chunks; the second is cut at 45 KB and resumes at 45 KB, not at the start. The server notes 14:09:48, seven minutes after capture, recomputes the fingerprint, finds it equal, writes the object and the thumbnails, and links the record to the file.

Two times are kept, and it is a rule: the device time, declared and editable by whoever sets their phone, and the server time, received and not editable. A seven-minute gap is a network cut; a three-day gap calls for an explanation, and the record makes it visible. WebP's gain over JPEG and the weight of a phone photo vary with the device and the scene; the sizes in the figure are a constructed example, and the weight of the screens that display these photos is covered in the slow application guide.

«The photo is reduced before being sent, never after: 240 KB gets through a weak network, 4.2 MB does not.»

In the field, in six gestures

What the agent, courier or technician does, in order, and why the second gesture is a rule.

Figure 3 · The accented step is a rule, not a feature: on a file that must prove something, the photo is taken in the application, not in the gallery, because an imported photo can come from anywhere and any time. The sixth step tells the agent where the upload stands without waiting.

Open the file: delivery, site, inspection; the expected photos are listed, façade, meter, parcel at the door. Shoot in the application, with the guided frame; on proof files, gallery import is disabled, because an imported photo can come from anywhere and any time. Check the list: missing photos are flagged before closing. Sign or get signed on the screen; the signature is linked to the file's photos and to the hand-over point, following the delivery without address guide.

Close the file, even without network; everything is queued. Let it go: the resumable upload runs in the background, and the state is visible, three pending, two sent, so the agent does not stand waiting for a progress bar. Continuous GPS, the camera and background work are among the reasons the agent's app is often native, following the PWA or native guide.

What makes a photo hold up

The figure shows the record of a stored photo, three checks made today, and the log of who saw it. All of that, not the image, is what holds.

Figure 4 · What makes a photo hold up is not the image: it is the record around it, the fingerprint computed at capture and recomputed today on the stored object, the object version showing it was never rewritten, and the log of who saw it through a signed link. A retouched copy gives a different fingerprint and fails. Values are a constructed example, and the legal weight of a photo depends on context.

The record carries the file, the author and the device, the two times, the position and its accuracy, the fingerprint computed at capture, the object's key and version, the rule on the full-size original, and the retention. The checks recompute today the fingerprint of the stored object and compare it with the record's: equal, the image is the one that was taken; a copy whose brightness was changed gives a different fingerprint and fails. The object's version shows it was never rewritten; object storage can lock a version for a period, as described in the backups guide.

Access is through a signed link that expires in fifteen minutes, and the log says who opened it and when; the large object stores themselves limit the life of such links to a few days at most. A dispute export produces a PDF with the fingerprints. The legal weight of a photo depends on context and is not covered here; what is built is the ability to show what was taken, when, by whom, and that nothing has changed since. Values in the figure are a constructed example.

«A photo alone proves nothing: what holds is the record around it, the recomputed fingerprint, the object's version and the log of who saw it.»

Six real situations, and what the application does

The six situations found in almost every field application we take over, and the construction that settles them.

Figure 5 · The first two rows are settled on the device, by reduction and the queue; the next two by the fingerprint, the two times and the shoot-in-app rule; the last two by signed access and written retention. None is settled by a more careful agent.

The first two rows are settled on the device, by reduction before upload and the offline queue; the next two by the fingerprint, the two times and the shoot-in-app rule; the last two by signed access and written retention. Reading the content of a photo automatically, an invoice or a note, is another subject, described in the AI document reading guide; here, the photo is proof, not a data source. None of the six rows is settled by a more careful agent.

Seen elsewhere: object storage, signed links and resumable upload, and what carries over

Three mechanisms of the large platforms carry over as they are. Versioned object storage, where every write creates a version and a version can be locked for a period; what carries over is never rewriting a proof object and keeping its version on the record. Signed links, limited in time by the provider itself, seven days at most with Amazon S3's tools and twelve hours from its console; what carries over is fifteen minutes for a file photo, and a log. Resumable upload, with tus, an open protocol for resuming an interrupted upload; what carries over is resuming at the chunk, on a network that cuts out.

What those mechanisms do not decide for you: the size you reduce to, original or not, how long you keep, and who may see; the project's first week answers that, and the manager signs.

The rules of a photo that holds up

Six rules, written in the first week. The proof photo is taken in the application, not in the gallery. It is reduced and fingerprinted on the device before any upload. It waits and leaves in chunks, and never restarts from the beginning. Two times are kept, the device's and the server's. The object is never rewritten, and its version is on the record. Access is signed, limited and logged, and retention is written.

And one rule of method: existing photos, on phones and in WhatsApp, are taken over as imported photos, marked as such, with the file date and no fingerprint at capture; you do not pretend they were taken in the application.

Six companies, and the photo that was missing

Six situations composed from projects we meet; the names are generic and the figures are examples.

A delivery company in Algiers, forty couriers. Hand-over photos left on WhatsApp and one disputed parcel in ten had no photo left. The construction: shooting in the application, offline queue, resumable upload, two times, signed link for the customer. Disputes without a photo stopped; the case is close to the cold chain guide.
A developer in Oran, buyers in France. Site photos arrived by e-mail, heavy and out of order. The construction: photos linked to the site stage, reduced on the device, thumbnails in the buyer's space; the case is described in the property developer guide.
An owner in Lyon, flat rented in Algiers. The inspection was a folder of photos with no reliable date. The construction: photos per room taken in the application by the manager, fingerprint, tenant's signature linked, retention for the lease duration; the case is described in the rented flat guide.
A solar installer in Sétif. End-of-site photos were disputed by a customer six months later. The construction: list of expected photos per site, two times, position, dispute export with fingerprints; the trade is described in the solar installer guide.
A car rental company in Constantine. Check-out and check-in inspections were done on paper. The construction: guided photos per side of the vehicle, departure and return compared side by side, fingerprint and signature; the case is described in the car rental guide.
A distributor in Annaba, twelve trucks. Unloading photos saturated the server and the screens. The construction: on-device reduction, thumbnails for lists, twelve-month retention on routine photos and five years on disputes.

The 2027 calendar

Six weeks for a company that already takes photos in the field; the first week passes without code.

Figure 6 · Six weeks, and the first without code: how many photos, what size, original or not, how long and who may see are the manager’s decisions, not developer settings. The second week is accented because on-device reduction is what makes photos arrive.

Week 1, rules: which files require photos and how many, what reduction size, original kept or not, retention period, who may see; signed by the manager. Week 2, capture and reduction: guided capture in the application, reduction and WebP on the device, fingerprint and metadata attached. Week 3, queue and upload: offline queue, resumable chunked upload, visible state for the agent, resume after cut tested by actually cutting the network.

Week 4, storage and record: receipt with server time and check, versioned object storage, thumbnails, record linked to the file. Week 5, access and export: signed links, access log, dispute export with fingerprints, display in files and on the customer portal. Week 6, retention and measurement: logged deletion at term, missing photos per file, first-attempt upload success rate. Every week ends with a demo, following the delivery without breakage guide.

What makes photos fail

Five causes, seen in applications we take over. The original sent then reduced on the server: the photo does not get through a weak network, and the server fills up. Gallery import on a proof file: the photo comes from anywhere. A single time: the phone's, which anyone sets. The public URL: the photo circulates. Photos in the database: the database grows, backups get longer, screens slow down.

And one cause of method: leaving retention “to decide later”. Without a rule, you keep everything forever, then delete in a panic; the first week exists to write it.

Frequently asked questions

The questions managers and founders ask when they describe photos that do not arrive or prove nothing.

Why do photos not arrive from the field?: Because they leave full size, several megabytes, over a network that cuts out, and an interrupted upload restarts from the beginning or is lost. The construction that settles this: reduction on the device before any upload, offline queue, resumable chunked upload that resumes at the chunk after a cut, and a visible state for the agent.
Should the full-size original be kept?: Only if the trade requires it, an expert assessment or a zoom on a detail for example, and that is written in the first week. For most proof files, a 1,600-pixel-wide photo is enough to read a plate, a meter or a defect, and weighs twenty times less. If the original is kept, it leaves after the reduced version, when the network allows.
How do you prove a photo was not retouched?: With a SHA-256 fingerprint computed on the device at capture, checked by the server at receipt, and recomputable at any time on the stored object; a modified image gives a different fingerprint. The object is versioned and never rewritten. That shows the stored image is the one that was taken; the legal weight depends on context.
Why two times on every photo?: Because the phone's time is declared and editable by whoever sets it, and the server's time is received and not editable. Both are kept; a gap of a few minutes is a network cut, a gap of several days calls for an explanation, and the record makes it visible instead of hiding it.
Where do you store thousands of photos?: In versioned object storage, not in the database: the database keeps the record, storage keeps the bytes, and every write creates a version. Photos are served through signed links that expire, never through a public URL. The choice of hosting location, Algeria or Europe, follows the dedicated guide.
Can photos already taken on WhatsApp be taken over?: Yes, as imported photos, marked as such, with the file date and no fingerprint at capture; they are linked to the file but the record says they were not taken in the application. You do not pretend.
How long does it take to set this up?: Six weeks in the typical calendar: one to write the rules, one for capture and reduction, one for queue and upload, one for storage and record, one for access and export, one for retention and measurement. The duration depends on the number of file types and whether a field application already exists.