I got as far as sketching the users table before I stopped.
The app was going to be an invoice generator for sole traders — the kind of person who sends four invoices a month and has been quietly paying $15–25/month for the privilege. The default architecture was obvious: accounts, a server, sync across devices.
Then I looked at what that table would actually hold. Business names. Tax registration numbers. Client lists. Billing histories. For thousands of small businesses, on my infrastructure, indefinitely, maintained by one person. I decided I didn't want to be responsible for it.
So PDF Pebble ships with no accounts, no sign-up and no server-side storage. Invoices, documents and business details live on the device. This is a design post rather than a code post — it's about what that removed, what it made harder, and what it cost.
What disappears when there are no accounts
More than I expected:
- No auth flow. No password reset, no email verification, no OAuth, no session handling.
- No sync conflict resolution.
- No user data to breach, subpoena or migrate.
- No data-subject-access machinery, because there is no subject data.
- No onboarding funnel. The app opens and works. The single biggest drop-off point in this category doesn't exist, because there's nothing to drop off from.
One precision, because "no backend" invites the wrong claim: the app is free and ad-supported, so it does talk to an ad network. Your documents don't go anywhere. The network isn't dead — the document path is.
Three things that got harder
1. Tax vocabulary is data, not conditionals
An invoice is not a universal object. An Australian tax invoice carries an ABN and says GST. An Indian one needs a GSTIN. The UAE says TRN. Europe says VAT. The US says EIN.
The tempting version is a chain of if (region == "AU") branches running through the rendering code. That collapses by about the fourth region, because the branches aren't only about labels — they're about which fields are mandatory, what the document is legally called, and which registration identifier is the one that matters.
Modelling a region as a data record — tax name, registration label, required fields — rather than as control flow was the change that made six regions cost roughly what two did.
2. One document model, two unrelated render targets
The same invoice has to come out as an A4 letterhead with a logo and a colour theme, and as a 58mm or 80mm thermal receipt.
Those are not the same document at different scales. A4 has typography, whitespace and brand colour. A thermal receipt has a fixed character width, no colour and no useful concept of a margin. Anything that assumes a page — a header block, a two-column layout — needs a receipt-shaped answer or it has to go.
Treating the invoice as structured data with two independent renderers, rather than as one layout that gets scaled down, is the only version that survives contact with a 58mm printer.
3. Status with no server as the source of truth
Invoices need tracking: draft to sent to paid, with a view of what's outstanding and overdue. Normally the server arbitrates that state.
With no server, the device is the source of truth, and "sent" means "I handed this to the share sheet", not "our SMTP server accepted it". That's a weaker guarantee and worth being honest about in the model: the app tracks what you did, not what happened to the email afterwards.
What it costs
I'd rather list these than get caught out on them:
- No sync. No second device, no phone-and-desktop continuity.
- No backup. Lose the phone, lose the data. This is the real one.
- No retention signal. No accounts means no cohort analysis, no activation funnel, no way to contact users. I traded the entire growth toolkit for a lower barrier and I'm still not certain that was right.
For someone sending four invoices a month I think it's the correct trade. For a growing business it isn't, and I'd rather say that than pretend the architecture generalises.
Scope, stated plainly
It does: guided tax invoices with six regional presets, ABN lookup by client name in Australia, A4 and thermal output, draft/sent/paid tracking, batch document scanning into a single PDF with edge detection, PDF merge, QR and barcode generation.
It doesn't: OCR — scanned text isn't searchable, and search matches file names only — password protection, e-signatures, editing inside an existing PDF, or cloud sync. Android and browser only; no iOS build yet.
Free, ad-supported, no subscription.
https://pdfpebble.com/?utm_source=devto&utm_medium=article&utm_campaign=launch
Disclosure: I built it. If you've shipped something offline-first, I'd genuinely like to know how you handled the backup problem — it's the objection I have the least good answer to.
Top comments (0)