SentryPDF
Problem
Die meisten Online-PDF-Tools verlangen, das Dokument auf einen Server hochzuladen, den man nicht kontrolliert – ein schlechter Deal bei allem, was auch nur ansatzweise sensibel ist. Ich wollte echte PDF-Werkzeuge anbieten, ohne dass Nutzer standardmäßig einem fremden Backend vertrauen müssen.
Was ich gebaut habe
Eine mehrsprachige Web-App für PDF- und Dokumentenverarbeitung, die ich im Alleingang konzipiert, gebaut habe und betreibe – Produktstruktur, UI, Auth, Zahlungen, Deployment und laufender Betrieb. Frontend mit Next.js/React/TypeScript/Tailwind/shadcn, Supabase für Daten und Auth, Stripe für Abrechnung.
Technische Entscheidungen
Die ursprüngliche Architektur verarbeitete alles clientseitig im Browser, sodass Dateien das Gerät der Nutzer nie verließen. Das funktionierte gut, bis große und wirklich komplexe PDFs die reine Browser-Verarbeitung zu langsam und speicherintensiv machten. Statt den lokalen Ansatz aufzugeben, entschied ich mich für ein Hybridmodell: Einfache, schnelle Operationen laufen weiterhin vollständig im Browser, während aufwändige Verarbeitung an kurzlebige Docker-Container auf Fly.io übergeben wird, die die Datei verarbeiten und danach sofort löschen. Das erhält die Datenschutz-Eigenschaft, auf der das Produkt aufbaut, während die schwereren Tools tatsächlich nutzbar werden.
Ergebnis
Live und im Betrieb unter sentrypdf.com, inklusive Deployment-Automatisierung über GitHub Actions und systemd-verwaltete Services – der gesamte Stack von der Produktentscheidung bis zum Produktivbetrieb liegt bei mir.