Online Tools Platform

Context

Portfolio sites attract a narrow audience — recruiters and hiring managers who arrive with intent. Tools pages attract a different kind of visitor: someone searching "free invoice maker online" or "assignment formatter no sign-up" who discovers the portfolio incidentally. This platform serves as both a traffic funnel for organic search and a live case study demonstrating product thinking and full-stack execution.

Problem

The portfolio ranked well for developer-specific long-tail queries but missed the broader "free utility tool" search market entirely. Adding a tools section would diversify traffic sources, demonstrate client-side engineering depth, and give the portfolio something genuinely useful to offer beyond self-promotion.

My Role

Solo developer across the full stack: architecture decisions, component design, library selection, PDF generation implementation, SEO metadata, and structured data for all five tools and the shared platform infrastructure.

Approach

The core architecture decision was RSC page shells with client-side interactive islands — the initial HTML is server-rendered for SEO and fast first paint, while the interactive tool logic (drawing, PDF generation, QR encoding) lives in client components that hydrate only when needed.

All five tools share a ToolLayout split-view component that renders a form panel on the left and a live preview on the right. This separation was deliberate: the preview area is rendered on a solid white background, which matters because html2canvas cannot capture CSS backdrop-filter effects — any glassmorphism in the preview would break PDF export. Designing the "print" area separately from the "display" area solved this cleanly.

Library choices prioritised stability over convenience. signature_pad (the original stable library) was chosen over react-signature-canvas (alpha-quality React wrapper) — wrapping the imperative canvas API in a React useEffect is a five-minute job that avoids a fragile dependency. jsPDF combined with html2canvas handles PDF generation for the document tools; it is not pixel-perfect but is "good enough" for utility tool output and has no server-side requirements.

Browser-only libraries (html2canvas, signature_pad) are loaded via dynamic import() to prevent SSR crashes. Each tool page has SoftwareApplication JSON-LD schema, a BreadcrumbList, and unique metadata targeting the specific long-tail search query for that tool.

Results

Every tool runs entirely client-side with zero server costs. Each page has full structured SEO data — SoftwareApplication schema, breadcrumbs, and tool-specific metadata — giving each tool its own search footprint independent of the main portfolio. The tools surface the same frontend engineering skills as the rest of the portfolio: component architecture, state management, responsive layout, and accessibility, but in a context that has direct utility for the visitor.

Learnings

html2canvas has well-documented limitations with CSS custom properties and backdrop-filter that are easy to miss in development (where the preview looks fine) but break export. The fix is architectural: keep the printable area independent of decorative CSS. This is a pattern worth knowing before reaching for html2canvas on any project.

Thin React wrappers over imperative canvas libraries are a recurring source of instability. When the underlying library is stable and well-maintained, a small useEffect wrapper is lower risk than a third-party React adapter that may lag behind or be abandoned.

Client-side PDF via html2canvas is a pragmatic choice for utility tools where pixel-perfect fidelity is not required. When it is required — invoices for accounting software, certificates for official use — a dedicated PDF rendering engine like Puppeteer or a server-side PDF API is the right tool.