A guest editor needs a draft handoff before sign-in

Aditya Jain — Thu, 10 Sep 2026 18:15:18 +0000

Disclosure: This article was generated by an AI assistant from Scopepaper's implementation and testing notes, on behalf of its creator, Aditya Jain. This is an implementation report, not a customer success story.

Scopepaper is a proposal editor for independent website and brand designers. Its public beta lets someone edit a sample and export HTML or print to PDF before creating an account. Sign-in becomes necessary when they want to save a proposal.

That ordering creates an easy-to-miss failure: a person can do useful work before authentication, then lose it while authenticating.

The test that exposed the problem was simple: change a deliverable and its price as a guest, follow the sign-in link, and return to the workspace. Checking whether login succeeded was insufficient. The edited proposal had to survive too.

Treat sign-in as a handoff

Scopepaper now keeps a temporary copy of the draft in session storage before leaving the editor. On the return path, it restores that draft, marks it as changed, and asks the person to save it explicitly.

The handoff has a few deliberate boundaries:

It expires after 30 minutes.
It is consumed once; reading it removes the stored copy.
Restoration creates a fresh draft identity instead of carrying a saved record's identity across accounts.
Fields and line items are validated before restoration. Malformed or expired data is discarded.
If storing the draft fails, navigation is stopped and the editor offers HTML export as a way to preserve the work.

This is a temporary handoff, not a durable backup. It does not promise recovery after closing the tab or returning hours later. The interface should not call it a cloud save.

Separate restoring from saving

Restoring the editor does not automatically create a database record. The person returns to their draft and chooses Save. That keeps an authentication redirect from silently becoming a content-creation action.

It also keeps the permissions boundary clearer: a browser-held draft is editable input, not proof that the current account owns a record. The server still needs to enforce ownership and saving limits.

The browser's unsaved-work warning also needs attention. A deliberate same-tab sign-in handoff should not feel like accidental data loss. Other attempts to leave a changed proposal should still warn the person.

Test the transition, not just each screen

For a guest-first editor, these are useful acceptance checks:

Change text and a price, sign in in the same tab, and confirm both changes return.
Confirm restoration does not silently save the draft.
Confirm malformed or expired handoff data cannot replace the editor with an invalid proposal.
Confirm a saved record's identity is not restored into another account's draft.
Check the storage-failure path: the person must see how to preserve their work before leaving.

The difficult part was the boundary between two individually ordinary screens. A working editor and working authentication do not, by themselves, make a working guest-to-account flow.

Try the current beta

Open the Scopepaper editor. Editing and export work without an account. ChatGPT sign-in includes three saved proposals total; paid checkout is not open. The app does not send proposals or collect e-signatures.

If you send proposals for freelance work, try changing one deliverable and its price, then export the result. What would you have to fix before sending it to a client? A made-up project is enough; no client data is needed.

DEV Community: Aditya Jain

A guest editor needs a draft handoff before sign-in

Treat sign-in as a handoff

Separate restoring from saving

Test the transition, not just each screen

Try the current beta