From the Guest Editor to a Saved Resume in Your Account

Guest work does carry over to an account, and the step that carries it is signing in, not saving. The order matters. Press Save in the guest editor and then sign in, and your draft gets written to your account. Sign in without pressing Save and there is nothing on your machine for the app to send up. Click back to the AceDraft home page as a signed-out guest before either of those, and the browser gets emptied.

Below are five stages stitched into one route, each linking to the post that covers it. I read those posts and the code they cite on 20 September 2026 rather than running the whole guest-to-account route in one sitting, so take it as a map, not a stopwatch.

Key takeaways

The hand-off lives in the sign-in callback. Once your login is stored, the app looks in browser storage for a guest draft and posts it to your account as a Draft.
It needs two pieces present: your form values and the rendered resume HTML. Save writes the first one.
Limitation: that write is best-effort. A failure goes to the browser console and sign-in carries on, so a lost draft looks identical to a saved one.
Limitation: sign-in drops you in the editor. Finding the resume is your job.
Opening the home page while signed out clears what the browser was holding.

Prerequisites. A browser, a resume you can finish in one sitting on one device, and a Google account by stage 3. No card until you want a polished file.

What are the stages of going from guest to account in AceDraft?

Five: build as a guest, press Save, sign in, find the resume on the dashboard, reopen it. The account only enters at stage 3, and everything before that is local to one browser.

Stage 1: Build the resume as a guest

Go to the guest editor. It has no route guard, which is what makes it a free resume builder with no sign-up step in front of the form. The guest editor walkthrough covers the template picker and every field.

Your work sits in your own device's storage while you type, in the browser's local storage on the web and a local database in the desktop and mobile builds. Each time the preview finishes drawing, the rendered resume HTML goes in. Your typed answers do not. Those only get written when you press Save, which is why Save matters more here than its name suggests.

Stage 2: Press Save and land on the export screen

Save writes three things into that storage and sends a guest to the export screen: your form values, a structured version of the resume, and the rendered HTML. The export screen post covers the free download and the paid card.

Nothing is on my server yet. The free download renders from that local copy and asks for no account, so you can leave with a PDF and skip stages 3 to 5 entirely.

Heads up. Landing on the AceDraft home page as a guest with no session wipes the stored keys, your draft included. The leg of the Google sign-in that passes back through the home page carrying a code is deliberately exempt. So the dangerous click is the casual one: going home to check something mid-draft.

Stage 3: What happens to my guest resume when I sign in?

It gets copied to your account as a Draft. That is the whole answer, so here is the mechanism rather than a reassurance.

Signing in from the paid card is a full-page Google redirect. The browser comes back carrying a code, which is forwarded to the app's sign-in callback. In that callback, straight after your login details are stored, a draft-hydration step reads the guest draft out of local storage and posts it to your account with the status draft, using the same payload shape the signed-in save path uses. That is why it arrives looking like any other resume.

Four conditions have to hold, all read in code on 20 September 2026: no draft id already stashed from a previous run, both the form values and the rendered HTML present, an email on the login that was just stored, and a live connection. Miss one and the step quietly does nothing.

If you wanted to save a resume online rather than in one browser, this is the stage that does it. There is no other moment in the guest route where a copy leaves your device.

The whole thing is wrapped so a failure is caught, written to the console, and ignored. Sign-in is never blocked by it. I wrote it that way to keep a broken save from locking someone out of their own login, and I got half of that trade wrong, because the same silence covers success.

There is a second, narrower carry-over: signing up from the Keyword Gap button inside the guest editor snapshots your form first, then restores it into the signed-in editor and reopens the keyword panel. That moves the screen you were on, not a copy into your account.

The callback then sends you to the signed-in editor, which is the same editor with a workspace rail around it.

Stage 4: Where does the resume show up afterwards?

On your dashboard, as a card with a Draft pill. The resume dashboard lists what is on your account, not what is in your browser, and the dashboard post goes through the cards, the counters and the search box. It sits behind the sign-in guard, so there is no link I can give you here that works signed out.

Arriving there has a side effect. Opening the dashboard clears the per-resume keys your browser was holding, including the draft id the sign-in step just stashed. The copy on your account is untouched. It is the local staging copy that goes.

Stage 5: Reopen it and keep working

Press Open in Editor on that resume's own page and your saved answers come back already filled in. Reopening a saved resume covers what returns.

Save from there does not overwrite. It writes your edit as a new resume and leaves the one you opened alone, so the list grows by one every time you finish an edit. Whether that is a feature depends on whether you wanted a version history or a single master file.

What this doesn't do yet

You might expect	What's actually there
A "continue on another device" link	Nothing. The draft is on one device in one browser until sign-in copies it up, and the sign-in that copies it up has to happen in that same browser.
The guest editor to reload your draft when you come back	It doesn't. A plain revisit restores your template choice, not your answers. The form values sit in storage unread until the sign-in step picks them up.
A message confirming the draft reached your account	None renders. Success and failure both pass in silence.
Paying on the guest export screen to file the resume under your account	The payment doesn't touch your resume. That screen's confirm step calls the payment-status route on my server, which checks the payment with the provider, records it, marks your account paid and writes a purchase row. No resume write anywhere in it. The resume reaches your account regardless, because the paid card won't take money from a guest: it makes you sign in first, and sign-in is the step that copies the draft up. Read in the front-end and the server route on 20 September 2026.
To land on your dashboard after signing in	The callback routes you to the editor instead.

Author's take

The shape of this route is right and the reporting on it is wrong. Letting anyone type a full resume before asking for an email is the only honest way to let someone judge an editor, and sign-in is the correct place to put the copy, because it is the first moment there is an account to copy into.

What bothers me is that four separate conditions can each make the carry-over no-op, and from the outside all four look the same as it working. If I touch one thing on this path next, it is a line on the dashboard saying where that Draft came from.

Use this if you want to try the editor before handing over an email address, you can finish in one browser, and you're willing to sign in once at the end to keep the work.

Skip this if you want to start on your phone and finish on a laptop. Nothing crosses devices before sign-in, and sign-in has to happen on the device holding the draft.

Building a job specific resume, the route that starts where this one ends.
The free ATS scan, worth running on the draft before you pay to polish it.
The AceDraft FAQ, for account and billing questions this post doesn't answer.