Things I have built and shipped.

The problem

Families living abroad want to look after relatives at home, but the money and the care are on opposite sides of a border. Sending cash is easy; making sure it buys the consultation, the lab test or the prescription it was meant to buy is not.

What I built

A single platform with three front doors — a web application, an iOS app and an Android app — over one Java API. The person paying and the person receiving care can be different people in different countries, which shapes almost every part of the data model.

• Appointments, lab test orders, prescriptions and physician report notes end to end
• Pay-on-behalf flows, so a relative abroad funds care delivered locally
• Full interface in English, French and Haitian Creole, including generated documents
• Server-side PDF generation from HTML templates for every clinical and order document
• Transactional email built on one shared, branded template system
• An educational video hub that ingests and organises content by condition
• A design-token system and component library, rolled out across the product in phases

The part that was hard

Three languages, three clients and one API means every change has nine places to be wrong. The fix was to move as much as possible to the server — documents, translated copy, business rules — so the mobile app and the web client stayed thin and could not drift apart.

The problem

Patients dutifully record their readings and end up with a spreadsheet nobody reads, including them. The numbers are only useful once someone explains what they mean and what changed.

What I built

A React progressive web app over a set of Spring Boot services, with a separate Python service doing the analysis. The architecture separates what is generic — users, content, notifications — from what is specific to one condition, so a second disease module can be added without reopening the first.

• Readings, medication adherence and symptom tracking, usable offline as an installed app
• Trend analysis over the reading history: rising, falling, stable, and by how much
• Plain-language weekly summaries generated from the patient's own data
• Risk scoring surfaced to both the patient and the clinician view
• An educational content service reusable across future condition modules
• JWT authentication through a gateway, with per-service database schemas

The part that was hard

A model that invents a reassuring sentence about someone's blood pressure is not a bug, it is a hazard. Generated text is constrained to the figures the service actually retrieved, and output that references anything outside that set is rejected before it reaches a screen.

The problem

Six-figure-line monoliths outlive the people who wrote them. The documentation is a decade stale, the architecture diagram is aspirational, and the only reliable source is the source. Most analysis tools give up on exactly these repositories: they do not compile, they have never had their dependencies installed, and they use a build layout nobody has used in fifteen years.

What I built

An open-source tool that reads source and git history directly, with no build required, and assembles a fact graph in a local SQLite file. Every row cites a file and line, a commit, or the build file it was read from — so no finding is an opinion.

• Packages, classes, endpoints, dependency-injection edges, routes and O/R mappings extracted from source
• Hotspots ranked by change frequency against complexity, and files whose history is one person
• C4 diagrams at all four levels, plus an ER model and the HTTP surface, as a self-contained HTML page with no network calls
• A diff between two runs, so CI can fail a pull request for the cycle it added and stay quiet about the six hundred it inherited
• An MCP server, so an AI agent working in the repository can ask structural questions instead of grepping
• Optional model-written descriptions under a citation check that rejects any sentence naming something the model was not shown

Why it matters commercially

It is the tool I reach for on the first day of a legacy engagement. Instead of a month of archaeology billed to a client, week one starts with a map.

The problem

The established players in this market share the same shape: a mega-menu of a hundred and fifty links, a configurator that hides its pricing rules, and a "call us for the exact width" message at the moment the customer is ready to buy. Every one of those is a place where an order is lost.

What I built

The commercial pitch rebuilt as an interface. A short, curated category structure instead of a wall of links, a live preview that renders the customer's own text as they type, and a price that breaks itself down line by line rather than arriving as a mystery total.

• Product configurator with live preview and an immediate size and price estimate
• Transparent line-item pricing, with the multipliers shown rather than buried
• A dedicated trade-pricing tier, surfaced rather than hidden behind a login
• Launched first as a single self-contained page for stakeholder sign-off before the full build

The part that was hard

Pricing rules that live in a spreadsheet in someone's head have to become code without losing the exceptions that keep the business profitable. That is an interviewing problem before it is an engineering one.

What I built

An Angular search application over an existing enterprise search engine: faceted refinement, result presentation that survives messy real-world documents, and a component structure the client's own team could extend without me.

• Faceted filtering and query refinement over a large heterogeneous corpus
• Result rendering tuned for documents of wildly varying quality and length
• A component architecture handed over with documentation for in-house maintenance

The part that was hard

Enterprise search fails on presentation far more often than on retrieval. The work was mostly about what to show first, what to collapse, and how to make a hundred results feel like an answer.

What I built

A Python service that ingests trade history and market data, an analysis layer over it, and a web client with charting for reviewing individual positions in context.

• Trade import, journalling and tagging, with the reasoning captured at entry rather than after the fact
• Charting integrated with a professional charting library, aligned to the journal entries
• An indicator and screening layer, including custom studies written for the charting platform
• Authentication and hosted deployment for use across devices

Why it is here

It is the project where I get to be my own difficult client. Everything in it — the ingestion pipeline, the charting, the analysis — is the same machinery a client-facing data product needs.