Divyanatha Reddy Dantu.

The problem

Staff repeated the same navigation for every client. The portal used nested shadow DOM, ignored synthetic input, and a click was never proof that a file had actually downloaded.

What I built

• A Manifest V3 service worker that turns a CSV worklist into a persisted, resumable queue that survives navigation.
• Deep shadow-root lookup and browser-level debugger input for controls that reject normal DOM events, with per-tab command serialisation.
• Completion tied to Chrome's download state — interrupted or missing files stop for review instead of being marked done.
• Per-client output folders and a spreadsheet status log with explicit done / partial / failed / skipped states. Sign-in stays with the user.

Shape of the system

1. CSV worklist
2. Persisted queue
3. Content scripts
4. Verified download
5. XLSX status log

The problem

Prospective clients want understandable numbers before a consultation — with the assumptions visible, and on whatever screen they happen to be using.

What I built

• Typed calculation modules shared across dynamic routes, each exposing its assumptions and warnings next to the result.
• Purchasing power that combines borrowing capacity with purchase costs through a bounded search.
• A source registry so every rate and rule points back to the reference it came from.
• Responsive Recharts visualisations, tuned until nothing overflowed from 390px to 2048px.

Shape of the system

1. Inputs
2. Typed calc modules
3. Assumptions + sources
4. Charts
5. Estimate, not advice

The problem

Practice staff needed structured rows from downloaded reports, but client documents had to stay on the machine and nobody should need Python installed to run it.

What I built

• A standard-library HTML parser that finds the expected table, validates fields and dates, and keeps source provenance on every row.
• Leading-zero identifiers preserved as text; malformed files routed to an exceptions sheet instead of silently dropped.
• A hand-written OOXML writer producing Records, Exceptions and Run summary sheets.
• PyInstaller builds for macOS and Windows, with the Windows package produced in GitHub Actions.

Shape of the system

1. Report HTML
2. Parse + validate
3. Records / exceptions
4. XLSX workbook
5. macOS · Windows

The problem

Organisers need one place for attendance, results and shared costs. Invitations have to respect court capacity, balances have to agree on every screen, and players need a clear next action.

What I built

• Capacity-aware invitations that close themselves when a session fills, with the roster as the single source of truth.
• A currency-aware ledger in integer cents — expense splits, payments and bounded settlement suggestions that match between personal and admin views.
• Change-signature idempotency keys so every distinct booking update sends its own email, and repeats don't.
• Adapters that normalise external court availability into one status model, plus calendar feeds and Elo-based doubles ratings.

Shape of the system

1. Clerk identity
2. Server actions
3. Roster + ledger
4. Prisma · Postgres
5. Email · ICS feeds