Libraro
A publishing platform preparing for a month-long writing event could not survive its own home page above roughly twenty visitors. I led the diagnosis and the stabilisation plan, contributed hands-on where it was fastest to, and took the tested load up by more than a hundredfold.
The problem
The business case was a one-month event expecting around 2,000 writers plus a considerably larger reading audience. The platform, as it stood, fell over with slightly more than twenty concurrent visitors on the home page.
The cause was not exotic. For every visitor, the backend queried PostgreSQL for the books shown on the page and then recalculated per-book data — comment counts, like counts — over and over. The work grew with both the number of books and the number of people looking at them.
What I did
- Investigated the platform's fragility and traced the performance bottlenecks to their source.
- Identified the inefficient PostgreSQL queries and data-access patterns behind the failures.
- Directed backend and PostgreSQL improvements across the delivery team, removing and restructuring the repeated query patterns.
- Contributed hands-on to selected bug fixes in the existing TypeScript/Node.js backend.
- Wrote Python recovery scripts that found the missing stages in interrupted document-processing workflows and reran them.
How it was verified
The improvement was measured with load and performance tests set at twice the client's modelled expected load — across concurrent users, request rate, uploads, and the reading, rating and commenting flows. In the tested scenario the platform supported more than 100× its previous load. The 2,000 figure was a monthly participant estimate, not a concurrency target, and I have kept those two apart deliberately.
The document pipeline
The product accepted manuscripts only as PDFs, while also requiring post-upload editing. Its custom PDF-to-JSON converter managed basic title and body content but struggled with lists, embedded images and multi-column layouts. We replaced it with Apryse, which handled complex structures substantially better — though not perfectly. We recommended DOCX as a more suitable editable source; the client chose to keep PDF-only uploads.
Workflow recovery
When conversion, AI processing or plagiarism checking failed after a successful upload, the manuscript was stuck in a half-finished state. My Python scripts identified which stages had not run and reran them. I also designed an admin-panel extension so the team could do this themselves; it was not implemented before the engagement ended. This was workflow recovery — not infrastructure disaster recovery, backup architecture or automated failover.
Partnership context
Hachette became a partner during the engagement, and the platform had to satisfy an extensive set of technical requirements as a condition of that partnership. I contributed to that work. The requirements themselves are confidential.
How it ended
I closed the engagement earlier than originally planned in order to take parental leave.