Command Palette

Search for a command to run...

portfolio.sh — v2.0.0
∗ initializing portfolio.sh... ∗
Full Stack Developer
experience·7+ yearslocation  ·Canadastatus    ·available ✓
scroll

// about.txt

Logic, creativity,
and a lot of code.

I live at the crossroads of logic and creativity. Before I wrote production code, I was running a digital marketing agency — managing campaigns, directing content delivery, and solving real business problems for clients across different industries.

The deeper I got into the web, the more I wanted to build it. I landed my first frontend role and never looked back. Today I'm a full stack developer building and supporting large-scale enterprise applications in Healthcare — working across the entire stack, from React interfaces to cloud-native infrastructure on AWS — serving 3M+ patients across North America.

Full Stack Developer

Vision Group Canada

$ git log --oneline

a3f9c12HEAD → main
Full Stack Developer · Vision Group Canada
2022 – present
7b2e891
Frontend Developer · Nippon Sake Imports
2020 – 2022
4d1a053
Frontend Developer · Contract
2017 – 2022
c8f3320
Digital Marketing Manager · WXLF Media
2013 – 2017

// projects

Things I've built.

// featured case study

EMR Platform

Vision Group Canada · 2023 – present

10+ clinics live and growing·3M+ patients·North America

The platform ophthalmology and refractive surgery clinics operate on. It carries a patient through the entire arc: referral in from a community optometrist, consult, pre-op workup, surgical scheduling, the procedure, post-op follow-up, and the handoff back to the referring optometrist.

Refractive surgery runs on a referral loop with physicians outside the organization. So the system has two populations with different trust levels — and only one of them belongs inside the EMR.

the boundary

Two front doors. One database.

Outside physicians never enter the EMR. They submit referrals through a separate co-management portal, built by a different team, in PHP, on separate hosting. The EMR stays internal: clinic staff, optometrists, ophthalmologists, surgeons, technicians, admins. A referral either attaches to a patient already on file or creates one. That boundary was organizational before it was architectural — a different team, a different stack, a different host. It happens to be a defensible design, but it wasn't drawn on a whiteboard.

the integration

S3 → Lambda → FSx

Two runtimes with nothing in common still had to exchange clinical documents. A referral document lands in S3; an s3:putObject event triggers a Lambda I own; the Lambda delivers into the FSx share, and the document surfaces on the patient's file. It's the unglamorous shape every senior engineer recognizes on sight — an event-driven cloud stack handing off to a consumer that only speaks files.

reporting migration

Reporting can't go dark while you replace it

Moving clinical reporting off SSRS/SQL Server onto Microsoft Fabric: DynamoDB → Lambda → S3, with Kinesis carrying changes through to Fabric. Clinic staff run their day on those reports — so the new stack was built alongside the old one and cut over at the end, on two Lambdas: one backfilling history, one carrying ongoing updates.

appointment dashboard

Built for receptionists, not for a generic staff user

Live appointment status for the clinic floor. The engineering was the smaller half: this was the first work where I owned the design requirements, working directly with a UI designer and a project manager to turn what clinics needed into something shippable. The heaviest users are receptionists, and building for them specifically is what made it land.

scope

Three years of full-stack feature ownership across the React/TypeScript/MobX frontend and the AWS backend — Lambda, DynamoDB, CDK — with infrastructure changes made in coordination with the team's CDK owners.

ReactTypeScriptMobXAWS LambdaDynamoDBCDKKinesisMicrosoft FabricDynamics CRMSharePoint

// side projects

investor-thesis/

2026

You hold an investment position for reasons. The world keeps producing evidence about those reasons, and you stop reading it. So: you write a thesis and the claims underneath it, and an agent loop researches the web and SEC filings on a schedule, scoring each new piece of evidence against each claim and tracking how the case moves over time.

the decision

The trace is the product, not a debugging feature

For output meant to inform financial decisions, an unauditable answer is worthless regardless of whether it's right. Every iteration persists both sides of the model call — request, response, tool calls, stop reason, token counts, duration — so a run can be replayed from the database. Unsourced evidence isn't discouraged, it's unrepresentable: the schema requires a URL, title, snippet, and the extracted passage. Each claim-evidence link carries impact, confidence, reasoning, and the version of the evaluator prompt that produced it, so verdicts from different prompt versions never quietly blend together.

the cost

Roughly triple the storage of keeping just the final answer, paid deliberately. The detail I'd point an interviewer at: partial is a first-class run status beside complete and failed, and there's a test fixture for the agent finding nothing. An agent that can't report finding nothing will always find something.

Next.jsTypeScriptAnthropicNeonpgvectorDrizzle ORMClerkInngest

wayfare/

2026

Booking confirmations arrive as a pile of unrelated PDFs. The itinerary exists only in your head. Upload the PDFs, a vision model extracts them into structured segments, and the app renders one daily itinerary with a live map and flags the gaps between stops.

the decision

Zod validates structure, not truth

A schema-constrained tool call gives you a well-formed answer. It tells you nothing about whether the answer is true. Malformed output is caught four different ways and always surfaces a readable error — but a confident, correctly-shaped, wrong extraction passes every guard. What partly covers for it is that wrong values tend to produce impossible itineraries: overlapping events, a flight landing after the hotel's check-in window closes, under 90 minutes between hotel checkout and departure. That catches misreads by their symptoms rather than their cause.

what's next

Datetime refinements and a cross-field check that arrival follows departure; editable segments so the human is the final validator; and surfacing the model's raw claim beside the parsed record — it's already persisted, it just has no reader yet.

Next.jsNeonDrizzle ORMMapboxClerkCloudflare R2InngestAnthropic

beacon/

2026

Uptime monitoring for HTTP services and domains. Live status streams to the dashboard over WebSockets, incidents open and resolve on their own, and it tracks DNS, SSL and domain expiry with email alerts.

the decision

Deliberately not serverless

Monitoring a serverless app from another serverless app is circular — your monitor shares a failure domain with the thing it's monitoring. So it runs as continuous Node processes on a VPS I own.

the cost

$12 a month, and a box that's mine to keep running.

TypeScriptNode.jsHonoNext.jsPostgreSQLDrizzle ORMWebSocketDocker

// skills

What I build with.

frontend

  • react
  • typescript
  • next.js
  • tailwind css
  • mobx
  • vitest

backend

  • node.js
  • rest apis
  • postgresql
  • dynamodb
  • drizzle orm

cloud & services

  • aws — lambda / s3 / fsx
  • docker
  • cloudflare r2
  • anthropic api
  • inngest
  • clerk

// send_message.sh

Let's build
something great.

// elsewhere

~$ open github.com/thiluxan-s
github.com/thiluxan-s
~$ open linkedin.com/in/thiluxan-s-b38599168
linkedin.com/in/thiluxan-s-b38599168
// direct email
thiluxan.s@gmail.com
available · responds within 24h