A Book You Can Read Online and Cannot Download

An independent author had a finished 406-page book and a specific, awkward requirement.

Readers who paid should be able to read it online. Nobody should be able to walk away with the file.

That is a harder problem than it sounds, and most of the obvious answers are wrong. A PDF behind a login is a PDF that somebody downloads once and shares forever. A DRM platform means handing over the book, the customer relationship and a revenue share to somebody else. A paywalled web version means retyping a book that is already typeset.

What we built

A login-gated reader in which the PDF never crosses the wire.

Every page is rasterised to an image at 300 DPI before publication, never in the browser, and served one page at a time to an authenticated session. The browser receives a picture of page 42, and only after asking for page 42 while logged in.

Layer	Choice
Frontend	Next.js 16, React 19, Tailwind, Radix, bilingual PT/EN
Backend	PocketBase, dedicated instance
Hosting	Our own VPS, Traefik with automatic TLS, EU-hosted
Email	Transactional provider, delivery verified into a real inbox with SPF, DKIM and DMARC all passing

Search is server-side. The index returns page numbers only, so a search never delivers prose to the browser. Zero characters of the manuscript reach the client through search.

Verified in production: a logged-out request for a page image returns 401. There is no bulk-download route. A valid session without access is denied.

The manuscript is not in the git repository and never has been. We audited the full history of both repositories, object by object: every blob is code or an application icon, and there are zero manuscript artefacts. No page images, no PDF, no search index.

The one thing we tell every reader of this study

The PDF cannot be downloaded. Individual pages can be screenshotted.

We told the author that before we built it, and we say it here for the same reason. A protection claim that overstates itself is worse than no claim, because it will eventually be tested by somebody who is annoyed.

What this design defeats is casual redistribution of the file. It does not defeat a determined person with a screenshot key and 406 pages of patience. Anyone who tells you their web reader does is selling you something.

The decision that removed most of the risk

Payments are out of scope, deliberately.

The author sells and collects. She confirms a paid reader and passes us an email address. The system creates the account and sends a one-time invite link, and the reader sets their own password.

To be exact about that, because "passwordless" is a word people overuse: we never send a password and the reader never receives one. The account is created with an unguessable throwaway that nobody ever sees, and the reader sets her own through a link that expires in 72 hours and can be used once. Re-inviting somebody kills the previous link, which the platform does not do on its own.

That single boundary removed VAT handling, invoicing, refunds and the entire card-data surface from the build. It is the least glamorous decision in the project and probably the highest-value one.

Verification

Republishing the whole book is a single command with a quality gate that has to go green before anything ships.

• 8 of 8 checks green: page count verified three separate ways, every page decodes, uniform dimensions across all 406 pages, and 0.000% word drift against the source.
• 587 render checks passed, 0 failed after publication. Every run also re-dims a real page by a known 0.35 and requires the estimator to recover it. It recovers 0.349, which is how we know the check can see the defect it screens for rather than merely reporting green.
• Roughly 7 minutes end to end to republish a real 406-page book, with no redeploy and no manual step.

We proved that last one with a drill on a deliberately different 376-page file, and the drill's first run failed: the server had the new book while the site still answered with the old page count, because a cache outlived the publish. That is what a drill is for. A second cache defect, this time in readers' browsers, only surfaced at the real publish and was fixed then.

We mention both because a publish process with manual steps is a publish process that gets done wrong at 11pm, and a publish process nobody has ever tried to break is not yet known to be one.

What is honestly not there

There are no reader numbers, because there are no readers yet. Every account on the system is ours. The reader is live and demonstrable. It has not been launched, the marketing site is unbuilt, and the launch date is the author's to set rather than ours.

We could have left that paragraph out. But a case study that quietly implies adoption it does not have is the same defect as a protection claim that overstates itself.

The part worth noticing

There is no AI in this product. None.

We checked rather than assumed: no model provider, no agent framework, nothing of the kind. The dependency list is a web framework, a database and a validation library.

The author's problem was never a problem that AI solves. It was a problem of access control and page rendering. We build AI systems for a living, and the correct answer here was not to use any, which is a decision we would rather be known for than the alternative.

If this sounds familiar

The pattern is not really about books. It is any piece of work that has value precisely because it is one file, sold to people who need to see it without being handed it: a report, a course, a dataset, a portfolio.

If that describes something you sell, it is worth twenty minutes of conversation.

This case study is published anonymised. No client, title or brand is named.