CASE STUDY
PDFRest API: Making Powerful Tools Accessible From Command Line to Cloud
IMPACT
Launched on AWS Marketplace; bug reports per feature ~10 to ~2 (80%); real-time outage detection with Sentry and CloudWatch
A SaaS-based API transformation project converting Datalogics' command-line applications into cloud-accessible services for file processing.
IMPACT AT A GLANCE
80%
Fewer bugs
TIMELINE
Enterprise development cycle
ROLE
Full-stack developer at Datalogics; led modular API and Lambda split
TEAM
Cloud engineering team with junior developers mentored through onboarding docs
THE CHALLENGE
Modernizing proprietary command-line tools into a scalable, web-based API platform. The original system ran as one large EC2 codebase, outages of up to about 28 hours could go unnoticed, and junior developers needed clearer paths to ship features safely.
THE RESULTS
- Successfully launched the SaaS API on AWS Marketplace as an enterprise self-hosted option
- Reduced bug reports per feature about 80%, from roughly 10 to about 2, after modularizing then splitting into AWS Lambda functions
- Eliminated 28-hour undetected outage gaps with Sentry error tracking and CloudWatch log monitoring for real-time incident detection
- Cut feature delivery time about 73%, from roughly 4 weeks to 1 week, by writing documentation and a developer first-steps guide (OpenAPI, Postman, JSDoc, local setup, reusable components)
- Established a foundation for scalable SaaS delivery of document processing tools
THE SOLUTION
First modularized the monolithic EC2 API so a central processing hub called individual endpoints with isolated logging. Then led the production split into separate AWS Lambda functions. Instrumented Sentry for issue counts and CloudWatch for logs. Built training materials with JSDoc, OpenAPI, and Postman plus a first-steps guide covering local setup and reusable components. Distributed the product via AWS Marketplace. Automation and usage analytics guided prioritization; TypeScript, Prettier, and Jest supported safer delivery practices on the team.
TECHNOLOGIES USED
- Node.js
- Docker
- Python
- Shell scripting
- AWS (EC2, API Gateway, RDS, Lambda)
- Sentry
- CloudWatch
- Jenkins
- AWS Marketplace
Project Details
What problem did the PDFRest API solve?
Datalogics had powerful document-processing tools locked in command-line workflows. Customers needed cloud-accessible APIs that could scale with demand and ship as a credible enterprise SaaS offering—including a self-hosted path on AWS Marketplace.
How did the architecture change from monolith to Lambda?
The starting point was one large EC2 server running the whole codebase. The first step was a modular API—a central hub calling individual endpoints, each with its own file logging—so a crashed endpoint did not take down the application. I then led the split into separate AWS Lambda functions that ran in production. Scaling scripts for vertical and horizontal growth existed on the team but were not my work, and Lambda cost savings are not claimed here.
How did monitoring and bug quality improve?
Before instrumentation, outages of one to two days—up to about 28 hours—could go unnoticed. Adding Sentry for issue counts and CloudWatch for logs made failures visible in real time and tied incidents back to bug reports. Bug reports per feature fell from about 10 to about 2 (roughly 80%). Stability is described through detection and bug quality, not an unverifiable single percentage.
How did documentation accelerate the cloud team?
Junior developers without full-stack experience were taking about four weeks (two two-week sprints) to land a feature. Documentation and a developer first-steps guide—local setup, reusable components, front-end to API wiring, plus OpenAPI/Postman/JSDoc training—brought typical feature delivery down to about one week, a roughly 73% reduction in delivery time. Mentoring preceded the guide; the guide locked the gains into the team's default path.
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.