Systems I have built and owned

Architected and own the production AI agent platform inside a multi-tenant Rails SaaS product — the assistants, routing, tooling, conversation state and evaluation infrastructure that turn LLM calls into dependable product workflows.

context

A multi-tenant SaaS product whose customers needed to build dashboards, query their data and produce reports without waiting on engineering. AI features had started as isolated interactions; the product needed a platform.

problem

Isolated AI interactions do not compose. Each new capability meant re-solving routing, permissions, conversation state and quality, and LLM behaviour was hard to trust in a product where tenants must never see each other's data.

role

DRI and technical owner: architecture, implementation strategy and delivery across system assistants, the report builder, analytics agents, routing, tooling, conversation state, tracking and export workflows.

decisions

Defined explicit assistant boundaries with routing between them instead of one ever-growing assistant. Built reusable tool abstractions so new capabilities plug into shared infrastructure. Treated evaluation as platform infrastructure, not a QA afterthought, and designed permissions and tenancy into the tool layer.

engineering

Multi-agent platform supporting dashboard creation, data querying, report generation, saved reports, CSV exports, embedded widgets and contextual hand-off between assistants. Evaluation-driven quality through deterministic tool coverage, regression-focused RSpec suites, date/query helper validation and observability workflows.

outcome

Customers build dashboards, query their data and produce, save and export reports through the assistants instead of waiting on engineering. New capabilities are added as tools on shared infrastructure, and regressions in agent behaviour are caught by the evaluation suites before release rather than by customers.

Ruby · Rails · PostgreSQL · Redis · Sidekiq · LLM APIs

Owned the architecture and implementation of the Airbnb integration for a hospitality platform: keeping bookings consistent between the product and external property-management systems.

context

A hospitality operations platform where reservations arrive from Airbnb, third-party PMS platforms and other booking providers, and must be allocated across multiple units without double-booking.

problem

Two systems each believe they own the booking. Synchronisation has to survive partial failures, late updates and multi-unit allocation, in a multi-tenant environment where a bug is visible to a guest standing at a door.

role

DRI for the Airbnb integration architecture and implementation, and for the synchronisation workflows between the platform and external PMS systems.

decisions

Designed booking synchronisation and multi-unit reservation allocation as explicit workflows rather than ad-hoc API calls, and invested in debugging tooling for multi-tenant environments so integration problems could be diagnosed without an engineer reproducing them.

engineering

Booking synchronisation and reservation allocation workflows; integrations with third-party PMS platforms and external booking providers; developer tooling for inspecting and debugging tenant state; work on scaling the booking infrastructure for reservation-heavy workloads.

outcome

Bookings from Airbnb and third-party PMS platforms flow into the platform and are allocated across units through one set of workflows, and integration problems can be diagnosed from tenant state without an engineer reproducing them.

Ruby · Rails · PostgreSQL · Sidekiq · Airbnb API

Led the development of a SaaS payment platform from the ground up as Tech Lead — technical planning, engineering workflows and release coordination.

context

A new payment product with no existing codebase: the technical foundation, the delivery process and the documentation all had to be created.

problem

Standing up a payments system from zero while keeping releases predictable for a team that was forming at the same time.

role

Tech Lead: owned technical planning, release coordination and the engineering workflow.

decisions

Invested early in CI/CD and in written solution investigations and workflow diagrams so decisions were visible to the whole team rather than held by one person.

engineering

Core platform development; CI/CD pipeline improvements that cut deployment time by roughly 25%; technical documentation and workflow diagrams.

outcome

A platform delivered from an empty repository with a repeatable release process, and deployments about a quarter faster than the starting point.

Ruby · Rails · PostgreSQL · CI/CD

Core architecture, large-scale web crawlers and crypto-exchange integrations for a data-heavy platform, over five years of growth and production hardening.

context

A platform built on data gathered at scale from the web and from crypto exchange APIs, with search and query workloads that grew with the dataset.

problem

Crawling at volume without being blocked, keeping exchange data consistent, and making search over a large dataset fast enough — while a legacy frontend and long-standing production issues slowed the team down.

role

Full-stack engineer with a key role in the core application architecture; owned crawling, proxy rotation and the exchange integrations.

decisions

Built proxy rotation as a system rather than a script; optimised the high-load search and query paths instead of scaling hardware; migrated the legacy jQuery frontend to Vue.js incrementally.

engineering

Large-scale web crawlers, proxy rotation, crypto exchange API integrations, high-load search/query optimisation, the jQuery → Vue.js migration, and the resolution of long-standing production issues affecting stability and data consistency.

outcome

A platform that stayed stable and consistent as the dataset and load grew over five years, with the long-standing production issues resolved and a frontend the team could keep evolving.

Ruby · Rails · PostgreSQL · Redis · Vue.js · Web scraping