Most invoicing products force signup before you can download anything. We made a different bet: guests can create a PDF invoice immediately, and drafts can survive a refresh on the same browser. That decision shaped privacy, architecture, and support tickets.
What “guest mode” actually stores
Guest invoices live in the browser via localStorage, keyed per draft. The server still renders PDFs when you ask it to, but we do not require an account row just to try the product. That means:
- Switching devices does not bring your guest drafts along.
- Clearing site data clears history.
- Shared computers are a bad place to leave unpaid client details.
We surface those trade-offs in the UI and push accounts when people need cloud history, teams, or the AI assistant.
Why localStorage instead of cookies?
Invoice drafts are larger than cookie limits and change often. Local storage keeps the payload on the client, avoids sending draft JSON on every navigation, and matches how people actually use a free tool: open tab, iterate, download, leave.
Security and support reality
Guest mode is not anonymous magic. Network requests for PDF generation still hit our servers. We rate-limit abuse, avoid indexing utility JSON endpoints, and keep legal pages clear about what we collect when you contact us or register.
The support pattern we see: someone builds five invoices on a laptop, then opens their phone and expects the same drafts. That is the moment an account stops being friction and starts being the feature.
Design lesson
Remove signup walls for the first success moment (download a PDF). Put the wall where the value changes (save across devices). If you reverse that, your activation funnel measures patience, not product quality.
Create a guest invoice at /invoices/create, or register when you want saved clients and history.