Devmith Amarasekara

The problem

A portfolio has to load instantly for strangers anywhere in the world, show up properly in search results and link previews, and still be something I can run, explain and extend myself.

What it does

Hosts my projects and background, with a hero avatar of me that turns to follow your cursor.

How it works

• Front end: Next.js with static export. Every page is pre-rendered to plain HTML at build time, so it works with JavaScript off and can be served from a CDN.
• Avatar: an AI-generated 3D bust, optimised from 22.5 MB to 699 KB. It loads only after the page has rendered, behind a still image of the same model, and only on devices with a mouse.
• API: a small Node service for view counts and the contact form (in progress).

Decisions

Rigging the avatar in code. The generated model was a single mesh with no skeleton, so a head can't turn on its own. Rather than rig it by hand in a 3D tool, the site builds two bones when the model loads and weights every vertex by height, with a blended band at the neck so it bends instead of tearing.

Phones get a still image. Without a cursor there's nothing to follow. Phones, tablets and visitors who prefer reduced motion get the poster instead — and never download the 260 KB of 3D code.

Nothing loads from third parties. Fonts are self-hosted at build time, and the model loader's default Google-hosted decoder is switched off. The site makes no requests anywhere but its own domain.

The problem

Automated border gates at international airports usually rely on e-passports. Travellers without one can't use them.

What it does

A secure, multi-role platform where travellers register their biometrics ahead of time, so they can clear an automated gate on arrival without an e-passport.

How it works

I built the Fingerprint Verification Module:

• A guided capture flow in React that walks the traveller through each step — right hand, left hand, then thumbs.
• A Spring Boot microservice that orchestrates fingerprint enrolment and one-to-one verification.
• A pluggable matching layer that can use either a custom OpenCV/Python minutiae-extraction engine or the SourceAFIS library.

All traffic between services goes through a JWT-secured API gateway.

Decisions

The matching engine is swappable, using the Strategy pattern. Both engines sit behind the same interface, and which one runs is a configuration setting. The rest of the module never knows which engine it's talking to, so the two can be compared, or one replaced, without touching enrolment or verification.

Fingerprints are stored as templates, never as images. PostgreSQL holds the mathematical template extracted from each print, not the picture of it. The database never contains a copy of anyone's actual fingerprint.

The problem

Phishing and social-engineering attacks against banking customers rely on pages that look right at a glance — a look-alike domain, a convincing login form. Most people can't tell in the moment.

What it does

A Chrome extension that checks every page as you browse. It combines fast local checks, reasoning by a language model, and a trust profile it learns for each site, and warns you before you hand over your details.

How it works

The extension runs in layers. I built the extension shell and Layer 1, the local detection engine:

• A content script re-scans every page on load and on each change to the page.
• It runs zero-latency checks locally: a registry of verified bank domains, Unicode homoglyph detection (look-alike characters, such as Cyrillic letters disguised as Latin ones), detection of subdomain abuse, and a scanner for hidden text that tries to inject instructions into the AI agent.
• The results are packaged into a structured signal object that the reasoning layer (Groq, Llama 3.3 70B) works from.

Decisions

Fast checks run locally, before any AI. The local layer costs nothing and answers instantly; the language model is used for judgement, working from what the local layer found.

One AI call per meaningful change. Pages change constantly. Re-scanning is gated on a fingerprint of the page, so a busy page triggers a new AI call only when something that matters has actually changed.

The extension defends itself, too. An agent that reads web pages can be attacked through them. Layer 1 flags hidden text aimed at the AI before the AI ever sees it.

The problem

When national exam results are released, portals put visitors in a queue and admit them a few at a time. A plain queue is unfair to students on slow rural links: the 450 KB results page can't finish loading inside the admission window, so they time out — and are sent to the back of the queue.

What it does

AAAC detects the quality of each visitor's connection and adapts both the admission window and the size of the page to match, so a slow connection gets a fair chance to finish.

The problem

A retail group with two depots, 120 outlets across three chains and a mixed fleet of refrigerated and ambient vehicles has to move goods from a store's request to its shelf. Every step involves a different person: the store manager, the dispatcher, the loader at the dock and the driver. If those hand-offs live in phone calls and spreadsheets, orders get lost between them.

What it does

One platform with a workspace for each role, all behind a single sign-in:

• Store managers request goods and confirm what actually arrived, or report a discrepancy.
• Dispatchers group orders into routes and allocate vehicles. Each vehicle is checked against capacity, temperature, depot, availability, fuel and route timing before it can be chosen.
• Loaders load each run from a checklist, deepest stop first, and flag problems before the truck is released.
• Drivers run their trips and capture proof of delivery (recipient, signature and photo). Their workspace keeps working offline and syncs when the connection returns.

How it works

A Next.js frontend talks to a FastAPI backend over PostgreSQL, with Keycloak handling identity for every role. I built the Store Manager workspace across the whole stack:

• The goods-request flow: items from the outlet's own catalogue, delivery-date rules (two operating days ahead, or next day for high priority before the cutoff), and a date picker that shows already-booked days.
• Receiving and discrepancy reports, including photo uploads.
• The backend API, models and Alembic migrations behind those screens, and connecting dispatch runs back to the store's orders so the store sees real progress.

Decisions

One sign-in for every role. The prototype had loaders pick their name and enter a PIN on a shared tablet. We moved everyone to Keycloak, so there's one login, one session model and one audit trail. To keep the shared-tablet use, the loader workspace keeps a quick Switch user and signs out after 10 minutes of inactivity.

A dock hand-off before loading. A run only reaches the loaders once the dispatcher has sent the vehicle to a dock and the driver has confirmed arriving there. A loader then picks the run, which locks it to them. This stops loading before the truck is there, and stops two loaders working the same run.

Mixed orders split by temperature. A request mixing chilled and ambient goods becomes two orders, one per temperature zone, so each can go on the right vehicle.

The problem

During large floods in Sri Lanka, aid isn't short; coordination is. Government agencies, NGOs and private donor groups all distribute relief at once, with no shared record of who has already been served. Roadside villages get several deliveries in a week while cut-off interior divisions get nothing.

What it does

FairReach keeps a live Coverage Ledger for every Grama Niladhari division: estimated need, what has been delivered, the resulting coverage deficit, which roads are passable, and which hospitals and shelters are open. Five agents read and write it. They take in reports in Sinhala, Tamil and English, rank divisions by unmet need, forecast which ones will be cut off, track road access, and dispatch teams.

The output isn't a map for someone to interpret. It's a dispatch instruction: this team, to this division, by this route, because these households are unserved, waiting for a coordinator's approval.

How it works

I owned the core that everyone else's agents write into:

• The Coverage Ledger: PostgreSQL with PostGIS, one row per division, with its boundary, household baseline, deliveries, deficit, access status and when it was last heard from. Every write goes through one repository layer and appends to an audit log recording who changed what, on what evidence.
• The orchestration graph in LangGraph. Agents don't message each other: the ledger is the shared state, and conditional edges decide at runtime which agent wakes next.
• Agent A2, the Coverage Analyst. It recomputes each division's deficit on every verified incident and delivery, and ranks divisions by unmet need, each with a confidence and a plain-language justification.

Decisions

Silence is evidence. A division that reports nothing may be fine, or may be cut off with no signal, which is where need is highest. The Coverage Analyst classifies quiet divisions as quiet because unaffected or quiet because unreachable, using connectivity, the division's normal reporting rhythm, river levels and road status.

Optimise for equity, not speed. The goal is to reduce the gap in coverage between divisions. Optimising for tonnage or delivery speed makes inequity worse, because the fastest deliveries always go to the easiest places.

The ledger is the blackboard. Because agents only communicate through the ledger, every decision leaves a trace in the audit log. That made the system explainable in the demo and let four people build agents in parallel against one published schema.

What it does

An instrument played by breaking laser beams. It works both as something to play and as a gamified way to learn.

How it works

• Notes: each laser beam shines on a light-dependent resistor (LDR); blocking a beam is detected as a note.
• Percussion: piezoelectric sensors pick up taps.
• Interface: an ESP32 drives a touch display, with the UI built in LVGL.
• Sound: MP3 and WAV playback through a VS1053B music shield.