Full stack engineer with 3+ years delivering production-grade software for a hospital in Ireland, a govtech startup, and an enterprise AI platform, not side projects, not tutorials. Real systems. Real stakes.
Most clients come to me when the complexity of their product has outgrown whoever built v1. Here's where I tend to make the most impact.
Each one shipped to production. Each one with real users, real constraints, and no room for shortcuts.
Everything here has been used in a real, live, production system, not picked up from a YouTube video the week before.
I don't ghost, I don't over-promise, and I don't deliver code that only works on my machine.
I'm not the right fit for every project, and I think that's worth being upfront about. The work I do best is for clients who have a real problem, a real product, and want an engineer who'll treat it that way.
I take on a limited number of projects at a time. If you have something worth building, reach out, I'll tell you honestly whether I'm the right person for it.
A hospital-grade LMS built for Cavan General Hospital in Ireland. The kind of system where a bug isn't a user complaint, it's a clinical risk.
Clinical laboratories are not forgiving environments. Every sample has a patient behind it. Every result feeds into a clinical decision. OCM was built to manage this entire chain, from the moment a sample arrives at the lab, through every test and result, to the final report in a clinician's hands, for a real hospital in Ireland with real patients.
This wasn't a greenfield toy project. It was a live healthcare system that had to be accurate, auditable, and reliable by default.
The constraint that shaped everything: In a hospital system, there is no "we'll fix it in the next release." Data integrity isn't a feature, it's the baseline. Every piece of backend logic had to be correct the first time.
Building for healthcare recalibrates your standards permanently. When your APIs are part of a clinical workflow, you stop writing "good enough" code. You write code that's correct, traceable, and that another developer can audit six months later. That standard now applies to everything I build.
A marketplace that removes the guesswork from government document applications, connecting citizens with registered couriers and walking them through every step with AI.
Government applications fail constantly, not because people are careless, but because the process is genuinely confusing. Wrong form, missing document, wrong courier, rejected on a technicality. HelloGov was built to eliminate that friction: match citizens with government-registered couriers, then guide them step by step through the application so it goes through right the first time.
The AI guidance layer was the product's core differentiator. My job was to build the backend that made it possible.
The core engineering challenge: Coordinating a two-sided marketplace, couriers and citizens, while also maintaining the application state that drives AI-guided step-by-step flows. Every piece of backend state had to be consistent, because the AI layer depended on it to be accurate.
HelloGov was my first deep experience with NestJS in a team environment, building services that needed to be clean enough for other engineers to work in confidently. It also reinforced something important: when the domain involves government processes and real documents, your backend's data consistency isn't just a technical concern, it's what the whole product promise depends on.
An enterprise platform for AI-powered voice and web customer engagement, built on a serverless microservices architecture with integrations across Stripe, Twilio, OpenAI, Anthropic, and multiple CRM systems.
Thinkrr AI lets businesses deploy intelligent agents that handle voice calls, web conversations, scheduling, support, and lead qualification, all from one platform. Enterprise clients use it to automate customer interactions at scale while staying connected to their existing CRMs, calendars, and payment systems.
I worked across the full stack: building enterprise UI in React, and contributing to a serverless backend that coordinates a significant amount of moving parts, AI providers, telephony, billing, async workflows, and third-party integrations, simultaneously.
The complexity that made this hard: A Lambda function handling a voice call might need to query a CRM, trigger an EventBridge event, update a PostgreSQL record through the shared data layer, and respond to Twilio, all within a tight latency budget. Getting this right meant understanding the whole system, not just your slice of it.
The backend runs entirely on AWS using the Serverless Framework, with each product domain as an independent service, voice agents, MCP, notifications, and more, sharing infrastructure through Lambda Layers:
Thinkrr is the project where full stack stopped meaning "I can do frontend and backend" and started meaning "I understand how every layer of a distributed system affects every other layer." When a voice call, a billing event, an AI response, and a CRM update are all connected, you have to think in systems, and ship accordingly.