I am a Financial Analyst on a twelve month industrial placement at Amazon, inside Amazon Leo (formerly Project Kuiper), Amazon's low earth orbit satellite broadband business, building a constellation of more than three thousand satellites.

• 01

  Took ownership of an AWS hosted internal deal approval platform used by 100+ employees across four functions. Introduced source control and a documented production baseline.

• 02

  Rebuilt its deal intake and approval flow to production standard, aligning legal, business, tax and finance on a single view of every deal.

• 03

  Build internal tools supporting finance workflows and financial modelling.

• 04

  Write SQL and Python to pull and transform data, and present the findings to stakeholders. Produce P&Ls and forecasts for deals.

• 05

  Run internal sessions helping other employees use AI tooling more effectively.

Enter a trip and a budget, and it tells you whether you can afford it, how many days the budget covers, and which changes would bring the cost down.

The estimate comes from a pure TypeScript engine with no framework imports and no I/O, reading a dataset of 8,271 cities baked into the app as JSON, so no request waits on an outside API or a database. Accommodation, food and local transport come from the destination city's cost-of-living data, falling back to the country median and then a global default, and each step down lowers the confidence tag on that line. Budget, balanced and comfort tiers change every category, and the trip month applies a seasonal multiplier that flips for the southern hemisphere.

The engine then reruns itself one change at a time (a cheaper tier, fewer nights, a cheaper month, a nearby city, one fewer traveller) and ranks the changes that save money. The verdict is comfortable, within budget, tight or over.

Version 1 was a Spring Boot 3 API on Java 21, a Python ETL worker and Postgres, with live fares from Amadeus. Amadeus closed its self-service API, the free database paused when idle and the JVM was slow to wake, so version 2 is a single Next.js app. The v1 code stays in the repo, and its Resilience4j circuit breaker is ported to TypeScript for any optional price source added later.

1. 1 Next.js 16 and React 19, one app
2. 2 Route handlers with a per-IP rate limit and zod validation
3. 3 Pure TypeScript engine, unit tested with vitest
4. 4 Baked JSON dataset, 8,271 cities
5. 5 v1 kept for reference: Spring Boot 3, Java 21, Python ETL, Postgres

Live demoGitHub repo

Exam revision that quotes your own notes back at you. It ingests slides, notes and lecture transcripts, turns them into quiz questions, and when you get one wrong it shows the passage that answers it.

Every question stores a short evidence quote that must appear word for word in one of the ingested chunks, and a question whose quote is not found is dropped before it reaches the quiz. The explanation for a wrong answer is built on the server from real chunks: the one holding the quote, plus up to two more from a pgvector similarity search. Spaced repetition puts untested and weak concepts first.

Every user request runs as a separate database role with Postgres row-level security forced on, so a query only returns that user's rows. That role cannot write scores or read the answer key; the server grades each attempt. 52 tests run in CI against Postgres with pgvector, covering the row-level security, grading and answer-key access.

1. 1 Slides, notes and lecture transcripts
2. 2 Ingest: clean, chunk, embed
3. 3 Postgres with pgvector, row-level security on the app role
4. 4 Question generation, evidence quote checked word for word
5. 5 Quiz with spaced repetition, confidence decaying over about 14 days
6. 6 "Why" panel built on the server from real chunks
7. 7 Hono API, Node 20 and TypeScript, JWT auth, static frontend

Live demoGitHub repo

Demo login: demo@example.com / revise-demo

A customer relationship assistant for a fictional retail bank, built on Google's ADK with Gemini 2.5 Flash. A root agent talks to the customer and hands the conversation to a complaints agent or a branch-finder agent through ADK's agent transfer, rather than hand written branching.

Lookups go through a separate read-only agent over BigQuery, which the root, complaints and navigator agents all call as a tool, so answers come from records instead of being improvised. Writes, such as a phone number change or a new complaint, go through plain Python tools with parameterised queries. Each agent's prompt lives in its own file, and an ADK evalset checks a lookup against the expected tool calls.

A pytest suite with BigQuery mocked covers the SQL each tool builds, the not-found and multiple-match paths and the agent wiring. CI runs it on every push.

1. 1 Root agent, handing off by agent transfer
2. 2 Complaints sub-agent
3. 3 Navigator sub-agent, Google Maps MCP
4. 4 BigQuery, read through a read-only bq_agent

Recorded runs, replayedGitHub repo

A group project for the Intelligent Robotics module. A simulated robot maps a building it has never seen and chooses where to explore next, using a particle filter SLAM system written from scratch in Python and run in Webots.

I wrote the SLAM core: the FastSLAM particle filter, the differential-drive motion model, the measurement model that scores each particle against the map, and the inverse sensor model that writes each LiDAR scan into a log-odds occupancy grid. My two teammates built frontier exploration and evaluation, and robot control with A* path planning.

It is a simplified FastSLAM: every particle shares one global map instead of carrying its own.

1. 1 LiDAR and wheel odometry in Webots
2. 2 Differential-drive motion model
3. 3 100-particle FastSLAM filter
4. 4 Occupancy grid, 400 x 400 at 0.05 m
5. 5 Frontier planner returning waypoints

Live demo, in the browserGitHub repoProject report (PDF)