Security

• Photographs cannot be edited or deleted after capture. Not by the tenant, not by the landlord, and not by us through the application.
• Every photograph is fingerprinted before it leaves the phone, and re-checked against the bytes we received.
• The time a record arrived comes from our database, not from anyone’s phone.
• A landlord reaches only their own rows. A tenant link reaches only that one tenancy. Both are enforced by the database.

The photograph, report, error and billing tables refuse UPDATE and DELETE. That is not a rule the interface follows — the grant is revoked from every database role, including the administrative one our own servers use, and triggers reject the operation on top of that.

So there is no code we could write, and no button we could add, that quietly removes a photograph from a walkthrough. Retaking adds to the history rather than replacing it. The trade-off is real and worth stating plainly: a deletion request is handled by us on the record as a whole, rather than by something that rewrites history in place.

Each photograph is hashed with SHA-256 in the browser, over exactly the bytes that will be uploaded. The server hashes what it received and compares. The result is stored beside the photograph and printed in the report.

Finished reports carry a fingerprint of their own. Both parties hold the same file, so either can check their copy against the other’s without taking our word for anything.

The time a record was received is set by the database clock, and no client role holds the grant to write it. A phone’s own timestamp is kept too, because it is useful, and is labeled “device-reported” everywhere it appears — a phone’s clock can be wrong, or changed.

Row-level security is on every table. A landlord’s session reaches their own properties, units, tenancies and reports and nothing else. A tenancy link resolves to exactly one tenancy: not the unit next door, not the tenant who lived there before, not the landlord’s other properties.

Those boundaries are checked against the live database rather than only reviewed by eye. The suite deliberately attempts things that should be refused — backdating a photograph, extending a link’s own expiry, writing another tenancy’s row — and fails if any of them succeeds.

There are no passwords. A landlord signs in with a one-time emailed link, so there is nothing to reuse, guess, or lose in somebody else’s breach. Keep access to that mailbox secure: it is the account.

A tenant never creates an account at all. Their link is the credential, it is scoped to one tenancy, and it expires.

Postgres and file storage with Supabase, hosting with Vercel, payments with Stripe, email with Resend — all in the United States. Card details are entered on Stripe’s own pages and never reach us. The full list, and what each receives, is in the privacy policy.

No security certification — no SOC 2, no ISO 27001. None has been obtained, and saying otherwise would be exactly the kind of claim this page exists to avoid.

Nothing here is a statement about how any record will be treated by a court or by anyone else. Walkthrough makes a record hard to alter; what weight that record carries is not ours to promise. The terms say so at greater length.

Backups are taken daily and kept for seven days. Point-in-time recovery is not currently enabled, so a fault could cost work done since the last daily snapshot. Download and keep your own copy of any report that matters to you — every signed report can be downloaded by both parties.

If you find a vulnerability, write to agallee36@gmail.com. It reaches a person, not a queue. We will not threaten anyone who reports a problem in good faith.