SentryPDF
Problem
Most online PDF tools ask you to upload your document to a server you don't control, which is a bad deal for anything remotely sensitive. I wanted to offer real PDF tooling without asking people to trust a stranger's backend by default.
What I Built
A multilingual PDF and document-processing web app I designed, built, and now operate solo — product structure, UI, auth, payments, deployment, and day-to-day operation. Frontend is Next.js/React/TypeScript/Tailwind/shadcn, with Supabase for data and auth and Stripe for billing.
Technical Decisions
The original architecture processed everything client-side, in the browser, so files never left the user's machine. That held up well until large and genuinely complex PDFs made pure browser processing too slow and memory-hungry. Rather than abandon the local-first approach, I moved to a hybrid model: simple, fast operations still run entirely in the browser, while heavy processing is handed off to short-lived Docker containers on Fly.io that process the file and delete it immediately afterward. That keeps the privacy property the product is built on while making the heavier tools actually usable.
Result
Live and operating at sentrypdf.com, including deployment automation via GitHub Actions and systemd-managed services — the whole stack from product decision to production ops is mine.