ACCEPTING PROJECTSOPEN

$ ls ./projects --featured

Selected work

02 / 06 · 5 ENTRIES

Five builds, five problems clients bring me in for: isolating tenant data on a shared backend, keeping slow work off the request path, turning labour law into a schema, modelling data around its reads, and serving many clients from one codebase. Each card covers the problem, what I built and the stack.

~/projects/techtiz2023 – 2024[ DEPLOYED ]

FEATURED · SAAS PLATFORM

Techtiz

Multi-tenant NestJS healthcare backend

THE PROBLEMTwo healthcare clients, each running multiple clinics, had to share one backend without patient data ever crossing tenants, and without every feature checking which client it served. Support ran through a third-party ticketing service that could not become a single point of failure.

Request flow: request → resolve tenant → inject db conn → handler# tenant logic never reaches application code

  • NestJS
  • Node.js
  • MongoDB
  • Multi-tenant architecture
Diagram of the database-per-tenant design in a NestJS backend. Three client apps — acme, globex and initech — send requests to one shared nest-api. Inside it, TenantMiddleware reads the x-tenant-id header, TenantService resolves the tenant's config, and ConnectionManager keeps a connection pool per tenant, so each request reaches that client's own isolated database: db_acme, db_globex or db_initech.
fig. database-per-tenant · NestJS

ENGINEERING CONTRIBUTION

  • Architected a multi-tenant NestJS and MongoDB backend with a dedicated database per client, isolating patient data for 2 healthcare tenants and their clinics on one codebase and one deployment
  • Engineered request-time tenant resolution that injects each client's database connection through NestJS dependency injection, keeping tenant logic out of every business module
  • Contained failures to a single tenant and held query performance steady as clients grew
  • Built a ticket support system on a third-party management portal, with fallbacks that kept client–support messaging running through provider outages
~/projects/daily[ DEPLOYED ]

FEATURED · AI · SERVERLESS

D[AI]LY

Serverless AI content platform

THE PROBLEMLLM calls are slow and unpredictable. The platform had to generate content and publish it to external CMSs on a schedule, hands-off, without inference time leaking into API response times.

  • Node.js
  • Express
  • React
  • AWS Lambda
  • S3
  • LLM APIs
Diagram of the AI blog publishing pipeline on AWS. A web app lets users edit, approve and schedule posts. An AI service handles keyword research and drafting, backed by a NoSQL keyword_db of trends and competition. AWS EventBridge fires scheduled jobs to a publisher, which posts to the WordPress and Webflow APIs. Failed publishes go to an Amazon SQS fallback with a maximum of 3 attempts, and a diagnostics service returns an actionable error to the web app, such as reconnecting WordPress and retrying.
fig. publish pipeline · AWS serverless

ENGINEERING CONTRIBUTION

  • Built the Node.js backend for a hands-off LLM content platform designed to scale to 10,000+ users, publishing with zero manual steps
  • Offloaded content generation and long model calls to dedicated AWS Lambda functions, keeping API response times flat regardless of inference time
  • Shipped scheduled publishing to the WordPress and Webflow APIs with media handling and automatic retries through Amazon SQS
~/projects/constructproCOMPLIANCE · FULL STACK

ConstructPro

Construction management platform (Swiss market)

THE PROBLEMSwiss construction firms need time tracking that obeys Swiss labour law and the LMV construction collective agreement: two kinds of overtime, weekly caps by worker group, per-canton holidays and five years of immutable records. It had to live inside a platform that also runs orders, clients, scheduling and accounting.

WHAT I BUILT

  • Delivered full stack features across order and client management, scheduling, PDF export and the Bexio accounting integration, owning the REST API contracts and data models for each
  • Designed a Swiss-compliant time-tracking module from scratch: two-bucket overtime (Überstunden and Überzeit), 45h/50h weekly caps, per-canton holiday calendars, Sollzeit and vacation logic, and five-year immutable records, with every rule traced to Swiss labour law (ArG, ArGV 1, OR) and the LMV
  • Eliminated full-table scans over five years of records by modelling a TimeLog / WeeklyTimeAggregate schema in PostgreSQL with pre-computed weekly rollups
  • Planned the module in independently shippable phases: schema, REST API contracts, then UI components
  • Automated the bug and feature workflow by wiring Trello to Claude Code through Pipedream webhooks, so a new card triggers a coding task directly
  • Node.js
  • React
  • PostgreSQL
  • REST APIs
~/projects/taleharborDATA MODELLING

Taleharbor

Social storytelling platform

THE PROBLEMA storytelling product lives on one read: a story's timeline, in order. The data model had to serve that read fast while staying available for 1,000+ concurrent active users.

WHAT I BUILT

  • Engineered a high-availability Node.js and MongoDB architecture serving 1,000+ concurrent active users
  • Modelled chronological story timelines as the core data structure and shaped read patterns around timeline retrieval
  • Node.js
  • MongoDB
  • React
~/projects/teamstartSCHEDULING · CI/CD

Teamstart

Scheduled event management

THE PROBLEMTwo clients needed scheduled events with their own configuration and predictable releases, without a separate fork of the product for each client.

WHAT I BUILT

  • Designed a semi-multi-tenant scheduling system that gave 2 clients custom schedules on one codebase, used by teams of 10–15 staff to schedule care for 100+ children
  • Automated development, testing and production environments with Docker and CI/CD for staged testing and predictable releases
  • Node.js
  • PostgreSQL
  • Docker
  • CI/CD