CASE STUDY
PDFRest Website: From Slow WordPress to Lightning-Fast Performance
IMPACT
88% decrease in page load time from ~7s to 0.84s (desktop PageSpeed/Lighthouse) while leading 2 junior developers
A website built for PDFRest SaaS product, transforming command-line tools into a user-friendly web interface with modern JAMstack architecture.
IMPACT AT A GLANCE
88%
Faster
0.84s
Load
TIMELINE
About 1 month redesign (team project)
ROLE
Led team adoption of newer technologies; full-stack development; mentored 2 junior developers
TEAM
Led 2 junior developers
THE CHALLENGE
Transitioning from traditional command-line tools to a modern SaaS platform with an accessible web interface, while replacing a slow WordPress stack that measured about 7–9 seconds page load time on desktop and was not mobile responsive.
THE RESULTS
- Cut page load time 88% from about 7 seconds to 0.84 seconds (desktop, PageSpeed Insights / Lighthouse)
- Rebuilt as a headless Jamstack front end on Vue, Nuxt, and Netlify
- Led 2 junior developers through the rebuild and redesign
- Created a Design Document library for improved developer experience
- Improved separation of concerns between frontend and backend
THE SOLUTION
Replaced the WordPress plus hand-written jQuery front end with a headless Jamstack site—Vue and Nuxt on Netlify—styled with Tailwind CSS and DaisyUI, with Ghost CMS for content. Stripe and Python services supported the SaaS product surface. Led two junior developers through the roughly one-month redesign and documented patterns so the team could keep shipping.
TECHNOLOGIES USED
- Nuxt
- Vue.js
- Python
- Stripe
- Netlify
- Tailwind CSS
- DaisyUI
- Ghost CMS
- JAMstack
- Docker
- AWS
Project Details
What was wrong with the previous PDFRest website?
The legacy site was WordPress with hand-written HTML, CSS, and JavaScript, a heavy jQuery front end, and a manual deploy process. It was not mobile responsive. Desktop page load time sat around 7 to 9 seconds—measured with Lighthouse and PageSpeed Insights—so product marketing and docs felt slow before users ever reached the tools.
How much faster did page load get?
After the rebuild, desktop page load time measured 0.84 seconds. Using the ~7s baseline, that is an 88% drop. Wording stays at page load time rather than LCP, because the original tooling reports confirm speed but not a locked LCP label.
How was the team organized for the rebuild?
I led two junior developers through the redesign over about a month. Beyond the public site, we produced a Design Document library so the cloud team could reuse patterns and keep frontend/backend concerns separated as the SaaS surface grew.
What stack replaced WordPress?
A Jamstack architecture—Nuxt for server-rendered Vue, Netlify hosting, Tailwind CSS with DaisyUI, Ghost CMS, plus Stripe and supporting Python/AWS pieces—gave PDFRest a product-ready marketing and product web presence without the old CMS deploy friction.
MORE WORK
OTHER CASE STUDIES
TrustClarity: Buyer Portal Rebuild — Search-First TC 2.0 Platform
IMPACT:
400+ Storybook stories across 130+ components (from 11), WCAG 2.1 AA remediation, RFQ flow with server-side credential fix, and 1,533 lines of storefront code removed for a search-first pivot
React/Next.js rebuild of TrustClarity's core buyer workflows — Figma-to-production, WCAG 2.1 AA, Storybook/Chromatic visual gates, and a search-first architecture that replaced the per-org storefront layer.
TrustClarity: Orchestrating Google Jules Multi-Agent Delivery on the Buyer Platform
IMPACT:
Four signed merges into develop covering AGENTS.md plus three UAT fixes; one additional thumbnail/search fix with a TypeScript no-suppression governance lesson; durable signed-commit / pull-and-re-PR playbook confirmed across later Jules rounds
Production orchestration of Google Jules on the TrustClarity buyer platform — first and second UAT rounds, signed-commit re-PR playbook, prompt discipline, and AGENTS.md governance that kept parallel cloud sessions safe to merge.
TrustClarity: Supply-Chain Security Analysis and CI/CD Hardening
IMPACT:
14 of 20 repositories remediated before TrustClarity production; 3 attack vectors eradicated; SHA-pinned reusable security-scan workflow rolled out to 20 repos; later SHA-pin and merge-base invisibility controls shipped
Org-wide supply-chain security analysis for TrustClarity — malicious code found in 14 of 20 repositories across three attack vectors, remediated in repos before it reached TrustClarity's own production environment, followed by a SHA-pinned reusable CI/CD security pipeline and later hardening controls.