Project Overview

Situation

League of Legends gives players extensive match statistics, but raw numbers rarely explain the decisions that actually led to a loss. Reviewing games manually to spot positioning mistakes, missed opportunities, and better alternatives takes significant time and game knowledge most players don't have.

Task

As co-developer working with one teammate over 4 months, my task was to help design and build an AI coaching platform that could turn raw Riot match data into personalised, explainable feedback benchmarked against high-elo play, at a cost the two of us could realistically sustain.

Action

I helped build an ETL pipeline that ingested match data from the Riot Games API, parsed game events into structured situations, stored everything in PostgreSQL, and generated statistical baselines from high-ranked players. We combined those datasets with vector embeddings in Qdrant and an LLM (OpenAI and Anthropic) to generate coaching reports, split the expensive processing into an offline pipeline so live requests returned quickly, and deployed the API to Google Cloud Run with the frontend on Vercel.

Result

The application was fully functional end to end, generating real coaching reports from live match data. To validate coaching quality, we had practising League of Legends coaches review the output and rate its usefulness and accuracy, which averaged 8.8 out of 10, with incorrect guidance appearing only rarely. What made the project unsustainable was cost: running the pipeline outside local development incurred high storage costs at scale, which was beyond what we could support as a self-funded two-person team, so we made the call to stop development rather than continue spending on something we couldn't realistically sustain long term.

Situation

Splitting study material across files and chat history has a real cost at revision time: re-reading whole documents to relocate one fact, or re-asking the same question because the answer is buried several conversations back. The tools weren't the problem; nothing kept track of where information actually lived.

Task

As solo developer and designer over 4 months, my task was to build a personal workspace where lecture material and AI conversations live together, so anything found or generated once stays attached to its source and stays findable later, rather than building another standalone chatbot.

Action

I built the ingestion pipeline (PyMuPDF, pdfplumber, python-pptx/docx, openpyxl) to turn uploaded PDFs, slides, and Office documents into structured, embeddable chunks, used pgvector on Postgres for semantic search, and ran background processing through async SQLAlchemy, Celery, and Redis. On top of that I layered an OpenAI-powered chat, per-document summaries and quizzes, and one-click study booklet generation, plus a CodeMirror-based live markdown editor with KaTeX math and Mermaid diagrams so generated notes stay usable, not just readable.

Result

The ingestion pipeline, semantic search, and AI-generated summaries, quizzes, and study booklets all function end to end on real uploaded material, and the retrieval system reliably keeps a generated answer attached to the document it came from rather than losing it in a chat log, which was the core problem the project set out to solve. The product is still in active development, with the next phase focused on refining the editor experience and expanding coverage of document types.

Situation

Most budgeting apps are good at recording what already happened and worse at answering the question users actually care about in the moment: can I afford this? Working that out meant manually tracking income, expenses, and upcoming costs just to know whether a purchase would leave a budget short later in the month.

Task

As solo developer over 3 months, my task was to build a budgeting app that turns a user's income, expenses, and spending habits directly into an answer, a daily spending limit and an immediate affordability check, rather than another transaction tracker.

Action

I built the app in Flutter on top of Supabase for Postgres and authentication, including Google and Apple sign-in, and added on-device receipt scanning using Google ML Kit's text recognition. I designed the daily spending limit as the core reference number, then built the “Can I Buy This?” affordability check, a category breakdown, a spending heatmap, and budget history statistics on top of it, along with a simple static marketing landing page.

Result

The daily spending limit, affordability check, receipt scanning, and spending insights all work end to end on real financial data, and building them shifted the app's focus from simply tracking transactions to directly answering the question users actually care about: can I afford this. That shift also showed how much the presentation of financial data matters, since a correct number is still unhelpful if it isn't immediately understandable. The app is in active development, with ongoing work focused on improving the accuracy of the budgeting calculations and refining the day to day experience.

Situation

Starting university makes it hard to meet people with similar interests outside lectures, societies, and existing friendship groups, and students working on projects often struggle separately to find collaborators with the right skills or interests.

Task

As co-developer and system designer working with one teammate over 8 months, my task was to design and build a single student network where social discovery and project collaboration could happen in the same place, rather than treating them as two separate products.

Action

I worked on the Kotlin Multiplatform and Jetpack Compose Android app and helped design the Supabase backend (Postgres, Auth, Storage, and Realtime), covering profiles, interest-based discovery, connections, messaging, and project collaboration. I used Ktor for networking, Paging 3 for feed pagination, Media3 for video, and ML Kit for on-device language and entity detection, and helped design the database schema and access rules behind features like the interest feed and society directory.

Result

Profiles, interest-based discovery, connections, and project collaboration all work end to end, but the bigger result was realising how much more is involved in a social platform than a typical CRUD app: supporting it properly meant designing for recommendation, content ranking, and interest-based matching between students, not just storing and displaying data. That understanding now shapes the backend and database architecture directly. The project is in active development, with the next stage focused on refining the UI now that those foundations are in place.

Situation

UKHSA's process for granting database access relied on several disconnected systems and manual steps. Users submitted requests through a web survey, requests were batched into a CSV once a day, and the file then had to be manually uploaded before a script could process each one, with sensitive datasets routed to a human approver. Requests could be delayed by the daily cycle, manual uploads introduced room for error, and administrators had no single place to see who had access to what.

Task

As Lead Developer and System Engineer on a 4-person university team over 10 weeks, my task was to design and build a single web application that could replace that fragmented workflow end to end (request, rules-based approval, database updates, and eventual access revocation), while working directly with the UKHSA client to keep the system aligned with their actual process.

Action

I designed the PostgreSQL schema and the rules engine that auto-approves non-sensitive requests and routes sensitive ones to an approver dashboard, and built the automatic 6-month expiry and renewal logic alongside audit logging for every request, decision, and permission change. I also added Resend and Twilio-based email and SMS notifications and CSV-exportable reporting, and helped run the weekly Zoom sessions with the UKHSA client to demonstrate progress and adjust the workflow based on their feedback.

Result

We delivered the completed portal and demonstrated the full request-to-approval workflow directly to the UKHSA client. The system met every requirement in the original specification and went beyond it with added email and phone verification, and the client was satisfied with the final result, giving the team practical experience of delivering against a real client's requirements.