Tharun Kumar

The problem

Which state-management approach to reach for is usually argued in the abstract. I wanted the comparison grounded in one real app, where the feature set is identical and only the state layer changes.

What I built

• Implemented boards, lists, cards, checklists and drag-and-drop against the official Trello API, with real-time sync and persistent cloud storage.
• Rebuilt the same app on four branches — plain React state, Context API, Redux Toolkit, and Redux Toolkit in TypeScript — each a complete working implementation rather than a sketch.
• Typed the store, actions and API responses in the TypeScript branch to see what the type layer actually catches once the app is non-trivial.

Outcome

Four deployable branches over one API, and a first-hand read on where Context stops scaling and where Redux Toolkit starts paying for itself.

The problem

Sharing a live location means streaming frequent GPS fixes to exactly the right people, keeping the map smooth on a one-fix-per-second signal, and never trusting a user id the client sends.

What I built

• Built a Node WebSocket hub with per-session rooms, an auth handshake sent as the first message (so tokens stay out of URLs and logs), token refresh, heartbeats and message-size limits.
• Verified Supabase access tokens against the project's JWKS on every REST call and socket, derived the user id server-side, and checked session membership in Postgres — with row-level security as a second layer.
• Wrote a reconnecting client with exponential backoff that rejoins sessions and flushes the latest unsent fix after a drop.
• Predicted positions between GPS fixes from speed and heading, and added road routing with distance and ETA by drive, bike or walk mode over OpenStreetMap.

Outcome

Deployed web app on Vercel and API on Railway, with a pub/sub seam in the server ready to swap in Kafka for multi-instance fan-out.

The problem

An AI reviewer has to run with secrets while reading code written by whoever opened the PR — so a PR must not be able to rewrite the reviewer, loosen its rules, or talk the model into leaking anything.

What I built

• Kept the review rules in a plain-English Markdown file of about 190 rules, grouped by severity (P0 to P3): secrets, injection, breaking API and schema changes, bugs, performance, tests, plus guardrails against false alarms.
• Ran the reviewer through pull_request_target from the base branch, so a PR can't change the reviewer or its rules, and fetched PR files as plain text through the GitHub API instead of checking them out or running them.
• Wrapped each file in a random per-run boundary the content can't fake, told the model file contents are untrusted, and never sent .env contents.
• Validated every AI finding against the PR diff (changed line, real file, valid severity), stripped HTML and @mentions, and skipped comments already posted on later pushes.

Outcome

Every push to a PR into main gets badged inline comments and one updated summary; a P0 finding fails the check, and main can only be merged once every comment is resolved.

The problem

Letting an LLM answer questions from a live database means it writes SQL you didn't write — so it must not be able to change data, read tables it shouldn't, or make up answers.

What I built

• Built an MCP server with six tools (list and describe tables, relationships, samples, summary, query) and turned its tools/list into Gemini function declarations, running a tool-calling loop with a round limit and deadline.
• Made the MCP server the only path to business data, through a separate mcp_readonly Postgres role with SELECT-only grants, read-only transactions, a statement timeout and a 100-row cap.
• Added a SELECT-only SQL guard and zod input validation in front of every tool, and tested it against 19 destructive or unsafe SQL attempts.
• Protected the chat and logs with Google sign-in (Auth.js), and recorded each question, generated SQL, tools used and answer in a searchable audit table.

Outcome

Deployed on Vercel with Supabase Postgres, running the real MCP protocol in-process so it works serverless; the same server also runs over stdio for MCP Inspector and desktop clients.