Where is a record saved when there is no signal?
On the phone first. Every record a crew makes in DEFECTED, a new defect, a packer count, a draw from a kit, a status change, is written to the phone's own database (IndexedDB, through the Dexie library) before anything is sent, and then delivered to the server by an outbox when the phone finds signal. The time a piece of work happened is fixed on the phone when it is recorded, not when it later syncs, so a shift worked out of signal is still attributed to the right day. Photos are saved on the phone in their own queue and uploaded when there is a connection; a failed upload is retried rather than dropped. The crew can see what is still waiting to be sent.
What happens to unsent work if someone signs out?
It stays on the phone. Signing out of DEFECTED never deletes the outbox or the photo queue, so work recorded underground and not yet sent is not lost because someone signed out, or because a shared phone changed hands at the end of a shift. When the app is opened again with signal, the queues carry on delivering. This is a deliberate rule of how the app is built, alongside two others that protect the record: changes to the database are additive and never delete crew data, and deleting a defect is a soft delete, so a deleted defect is kept and can be restored rather than disappearing. Engineers' decisions work the other way round: validating or sending back a defect needs a connection, and is never queued, so a decision is either accepted by the server at once or not made at all.
Who can see and change what?
What a person is on a project, technician, labourer, supervisor, engineer or admin, is set on their account by an admin, not chosen by the person, and nobody can change their own role. Access is enforced in the database, not only in the app: row-level security is turned on for every table that holds the app's records, and its policies check whether the person belongs to the project the record is in. In the app, crews see their own work stream. Closing a defect goes through a database function that accepts a validation only from an engineer or admin of that project who is not suspended, and only for a defect that is actually awaiting validation; the database refuses the Validated status from any other path, and two engineers cannot decide the same defect at once.
How is the history of a defect kept?
By the database. Every status change on a defect, from any phone or screen, is written to the defect's history by a database trigger, with who made it and when. That history table has no policy that lets anyone insert, change or delete rows: only the trigger writes to it, so nobody can edit or delete the history from the app. Comments that come with a change, an engineer's reason for sending a defect back or a crew's reason for reopening one, travel with the change and are kept word for word, even when the change syncs hours later. Photos carry their capture time burned into the image, taken when the camera returned the photo rather than when it uploaded. Together these make the record say who did what and when, without relying on anyone's memory.
Where is DEFECTED hosted?
The database, sign-in and file storage run on Supabase. The web app at defected.app and the server functions that build scheduled reports run on Vercel. Crews use the same app on iPhone or in the browser. When a person deletes their account from inside the app, the defect records, kit logs and reports they produced are kept with their name removed, because they are the client's records of the work. How personal information is handled, and how to ask about it, is set out in the privacy policy. For anything this page does not answer, email hello@defected.app.
To see how the record holds up on a live job, read the Sydney Metro West Portion 1 case study, or start a 14-day pilot.