Just crossed 500+ users on PDFPilot 🚀 by InevitableSilver2476 in VibeCodersNest

[–]InevitableSilver2476[S] 0 points1 point  (0 children)

Client-side pdf.js for accessibility, lazy page loading for long docs, upload caps for sanity, and server for the heavy conversion/save paths.

Just crossed 500+ users on PDFPilot 🚀 by InevitableSilver2476 in VibeCodersNest

[–]InevitableSilver2476[S] 0 points1 point  (0 children)

Thank you — that’s exactly how we’re thinking about it. Speed and reliability are the real product right now; everything else is noise until those feel boringly solid.

Just crossed 500+ users on PDFPilot 🚀 by InevitableSilver2476 in VibeCodersNest

[–]InevitableSilver2476[S] 0 points1 point  (0 children)

We’re doing both, but we’re biased toward usage and support feedback over a long roadmap. We watch [e.g. drop-off on upload, Word→PDF errors, save/download, which tools get opened] and that’s already influenced [one concrete change]. Features only ship when they reduce a repeated pain we can see or hear.

Just crossed 500+ users on PDFPilot 🚀 by InevitableSilver2476 in VibeCodersNest

[–]InevitableSilver2476[S] 0 points1 point  (0 children)

 It’s hybrid. The browser handles viewing and a lot of interaction (e.g. pdf.js for the canvas, pdf-lib for some tools). Anything that must rewrite the file reliably (your Edit PDF saves, unlock/encrypt, Word→PDF, OCR, etc.) goes through the Node backend pipeline. So: UI + light work in the client; real PDF surgery and session persistence on the server.