ACCEPTING PROJECTSOPEN

$ ls ./projects --featured

Selected work

02 / 06 · 4 ENTRIES

Four projects that show the problems I usually get brought in for: keeping clients' data apart on a shared backend, keeping slow work off the request path, modelling data around how it is read, and serving many clients from one codebase without forking it. Each one covers the problem, what I built, and the stack.

~/projects/techtizSAAS PLATFORM

Techtiz

Multi-tenant NestJS backend

THE PROBLEMA growing set of client applications had to run on one backend without their data ever mixing, and without every feature needing to know which client it was serving. Support also ran through a third-party ticketing service that could not be allowed to become a single point of failure.

WHAT I BUILT

  • Architected a multi-tenant NestJS backend with a dedicated database per client — isolating each client's data, improving security and performance, and keeping a growing set of client applications manageable
  • Resolved the client on every incoming request and injected that client's database connection at request-processing time through NestJS dependency injection, so each request ran against the correct database and schema with no tenant logic in application code
  • Built a ticket support system around a third-party service acting as a centralised management portal, with fallback mechanisms so two-way client–management communication stayed uninterrupted when the provider did not
  • NestJS
  • Node.js
  • MongoDB
  • Multi-tenant architecture
~/projects/dailyAI · SERVERLESS

D[AI]LY

AI content generation platform

THE PROBLEMContent was generated by LLM calls that are slow and unpredictable in duration, then published to external CMSs on a schedule — all without manual intervention, and without inference time leaking into API response times.

WHAT I BUILT

  • Built the backend for an LLM-driven content platform engineered to scale to 10,000+ users, generating and publishing without manual intervention
  • Offloaded generation and long-running model calls to dedicated cloud functions, keeping the request path responsive independent of inference duration
  • Implemented scheduling and publishing workflows against third-party CMS APIs (WordPress, Webflow) with media handling and retry logic
  • Node.js
  • Express
  • React
  • AWS Lambda
  • S3
  • LLM APIs
~/projects/taleharborDATA MODELLING

Taleharbor

Social storytelling platform

THE PROBLEMThe core read in a storytelling product is a story's timeline, in order — so the data model had to be built around retrieving timelines quickly, while the platform stayed available for 1,000+ concurrent active users.

WHAT I BUILT

  • Engineered an architecture supporting 1,000+ concurrent active users with high availability
  • Modelled chronological narrative timelines as the core data structure, with read patterns designed around timeline retrieval
  • Node.js
  • MongoDB
  • React
~/projects/teamstartSCHEDULING · CI/CD

Teamstart

Scheduled event management

THE PROBLEMSeveral clients needed scheduled events with their own configuration, and releases had to stay predictable — without maintaining a separate fork of the product for each client.

WHAT I BUILT

  • Designed scheduled event management on a semi-multi-tenant architecture, serving customisable scheduling to multiple clients without per-client forks
  • Automated development, testing and production environments for staged testing and predictable releases
  • Node.js
  • PostgreSQL
  • Docker
  • CI/CD