When we started building NeedAnyTool's PDF utilities, one architectural decision affected almost everything else: where should document processing happen?
For supported operations, we wanted processing to happen inside the browser rather than requiring every PDF to be sent to a backend.
Why this architecture interested us
PDF utilities often work with sensitive files:
- invoices
- resumes
- contracts
- IDs
- academic documents
If an operation can be performed locally, sending the source file to a remote server introduces infrastructure and privacy considerations that may not be necessary.
Our web architecture
NeedAnyTool is built with Next.js and organizes its utility products under the same application:
**/pdf/
/image/**
Each tool owns the client-side functionality it requires while shared concerns such as analytics, SEO and navigation remain centralized.
Keeping heavy processing away from unrelated pages
One important consideration with a utility platform is bundle size.
The homepage should not download PDF-processing libraries simply because a Merge PDF tool exists elsewhere in the application.
Heavy processing dependencies are therefore loaded only where they're required.
Analytics without document data
We want to understand whether a tool actually helps users complete their task.
So our analytics focuses on actions such as:
- tool_start
- tool_complete
- tool_download
rather than collecting filenames or document contents.
That gives us useful product information while keeping the analytics separated from the user's actual document data.
What we're building toward
NeedAnyTool currently includes PDF and Image utilities, but we're designing the architecture so additional categories can be introduced without turning the application into a collection of unrelated standalone projects.
We're still improving this architecture, and I'd be interested in hearing how other developers approach browser-based document processing.
Top comments (0)