An automatic backup feature is not a single boolean. On the first run, it is a dependency graph.
The dependency chain
desktop installed -> receive destination ready -> pairing credential ready -> mobile installed -> devices paired -> automation enabled -> network eligible -> first object received
This ordering matters because each failed node needs a different support action.
Keep pairing separate from automation
Pairing answers whether a phone is connected to the intended computer. Enabling Automatic Backup answers whether the user wants new photos and videos to upload automatically.
Combining those states in one label makes diagnostics harder. A paired device may still have automation disabled.
Make network eligibility explicit
In LynavoDrive, initial setup requires public internet access. After setup, Automatic Backup can work while the phone and computer share a LAN even if public internet access is unavailable.
That gives the runbook two distinct network states instead of one vague online/offline flag.
Define the first passing event
The first-run flow passes when one newly created photo appears in the configured receive folder and opens on the computer.
The product transfers the original file without intentional compression. Phone and computer deletions are independent, so this passing event does not establish full two-way sync.
Screen-off and background transfers are separate paid states in the official build. They should not be inferred from an app-open first-run test.
Disclosure: I work on LynavoDrive. Current install sequence: https://drive.lynavo.io/download.html?utm_source=devto&utm_medium=article&utm_campaign=first_backup_setup_20260803
Top comments (0)