Tanmay Singh

The idea

Most workout trackers are either fast but flat, or gamified but slow to log. Mettle tries to be both: logging comes first, the game second. Showing up earns steady XP, crossing real strength and running benchmarks earns a lot of it, and everyone climbs from E rank to S rank (six ranks, five levels each).

Benchmarks are relative, not absolute: they’re normalised for bodyweight, age and sex, so a 75 kg lifter benching bodyweight is compared fairly with a 120 kg one. The rules also avoid rewarding unhealthy behaviour: cardio XP has diminishing returns and rest days don’t break streaks.

How it works

• Offline-first logging: workouts are written to SQLite on the phone (Drizzle ORM), because gyms often have bad reception. Signing in is optional; when you do, data syncs to Supabase.
• One XP engine, two places: XP is derived from logged sets by a pure TypeScript engine. The same code runs in a Supabase Edge Function, so leaderboard XP is recomputed server-side and can’t be edited on the phone.
• Real standards: 325 exercises (public-domain catalogue plus Mettle’s own), strength and rep standards, and WMA/USATF age-graded running tables decide benchmark tiers and your starting rank.
• Social: friend groups with weekly leaderboards, profiles with goals, and routines you can share by code.
• Security: Postgres row-level security on every cloud table, Google or email-code sign-in, and full account deletion.

Stack

React Native + Expo (TypeScript), expo-router, Reanimated, expo-sqlite + Drizzle, Zustand, Supabase (Postgres, Auth, RLS, Edge Functions), Jest with 220 tests across the engine, SQLite integration, sync and server.

Status

In active development and not public yet. Builds go to a small group of testers through EAS. If you’d like to try the beta, use the button below.

The idea

A vintage photobooth that lives in the browser. You step inside, strike four poses, and get back a developed photostrip, like the booths in old malls and train stations. You can use it in the Booth section of this page. Inspired by mysketchbooth.com.

How it works

• Shoot or upload: four shots from a phone or laptop camera, each with a 3-2-1 countdown and a flash, or four uploaded photos cropped to 3:4.
• Set up the shot: 16 frames (from Classic Black to Film Negative, Ticket Stub and Pressed Flowers) and backdrops: your own room, or a painted white wall, studio grey, black or velvet curtain, with a live preview of your own face.
• Cut-out backdrops: a MediaPipe selfie segmenter, self-hosted and running on-device, separates you from the room so you can stand in front of a painted backdrop, with a flash shadow behind you.
• The darkroom: a canvas pipeline develops the strip with flash glow, edge burn, black-and-white or film-colour toning, paper grain and dust. An “authentic” mode adds a harsh close-flash look: blown highlights, crushed blacks, halation and heavy grain.
• Take it home: save it (straight to Photos via the share sheet on phones), share a 1080×1920 story image, print it on A4, or cut the strip into four single prints. Every strip you make is kept in a gallery in your browser.

Six booths

Retro ’70s, Sketchbook, Darkroom, Pixel Arcade, Photo Boy and Hello Kitty & Friends. Each theme is just decor: the pages own all the behaviour, so a new booth is one new file.

Privacy

Everything runs client-side. Photos are processed on your device and stored in your browser’s IndexedDB; nothing is ever uploaded.

Built with React, TypeScript, Vite, Tailwind CSS, Framer Motion, the Canvas API and MediaPipe.

The problem

Delhi’s air is among the worst of any major city, and it swings hard: PM2.5 can triple in a few days when crop-residue burning in Punjab and Haryana meets still winter air. Most public sites show what the air is like now. CheckYourAQI forecasts it for each of 70 government monitoring stations 24, 48 and 72 hours ahead, and is upfront about how accurate those forecasts are.

How it works

• Ingest: hourly and daily pulls from OpenAQ (station PM2.5), Open-Meteo (weather and the CAMS air-quality model) and NASA FIRMS (satellite fire detections), orchestrated by Airflow on EC2.
• Model: a bronze → silver → gold lakehouse on S3 and Iceberg, built with 27 dbt models on Athena and guarded by 44 data tests.
• Forecast: one LightGBM model per horizon predicts every station every hour. Retraining runs weekly on GitHub Actions, and a challenger is promoted only if it beats production on data production has never seen.
• Serve: a Streamlit dashboard and a FastAPI read API on Lambda, both reading a small public Parquet snapshot so neither touches AWS credentials.
• Operate: Telegram alerts when a task fails or the data source goes down or recovers. The whole thing runs unattended for about $21 a month.

Results

Walk-forward validation over 14 months (647k training rows). Mean absolute error in µg/m³, lower is better:

Horizon	LightGBM	Persistence	Same hour, last 7 days	CAMS
24h	31.4	33.6	33.2	61.6
48h	33.8	38.5	34.1	62.6
72h	35.2	40.0	34.9	63.4

Design decisions

• No leakage, enforced by a test. Features use only data available at prediction time, and a dbt test fails the build if any input post-dates the prediction. The same SQL macro builds training and live features.
• UTC everywhere, IST only on screen.
• Honest about stale data. Stations and the feed are classified live, delayed, inactive or outage, and forecasts built from stale inputs say so.

The problem

Large parts of Mesa, Arizona have no bus service at all. This graduate project at Arizona State University (FSE 570) asked where new routes would help most, and what they would do for emissions.

Method

• Find the gaps: joined ACS population data to census tracts in QGIS and overlaid the existing network, which left 63,413 residents in tracts with no transit.
• Design routes: proposed 5 new bus routes with 45 stops along major arterials, then used 500 m walking buffers intersected with tracts to check who each route actually reaches.
• Cost it: brought the city’s transportation budget into the same pipeline for preliminary route-expansion and operating cost estimates.
• Model emissions: compared diesel and electric buses across 5–15% ridership uptake, two trip lengths and two occupancy levels, using national per-mile emission factors.

Results

Across all 24 scenarios the routes save about 8,078 metric tons of CO₂ a year on average. Electric buses nearly double the benefit at high uptake: roughly 22,800 t a year at 15% uptake, versus 15,400 t for diesel (20 riders per bus, 12-mile trips).

Built with QGIS, Python, GeoPandas, pandas and Matplotlib on public data (ACS, OpenStreetMap, bus ridership records).

The problem

Writing data-quality checks by hand is tedious, so they often don’t get written. CheckYourData lets you upload a dataset and has an AI agent propose validation checks from its schema, which you review, edit and run.

How it works

• Upload a CSV. The backend profiles its columns and stores the dataset.
• Suggest: an agent sends the column schema plus a small sample to Claude, using forced tool-use so the response is always a structured list of check configs. Malformed suggestions are caught by validation and retried automatically.
• Review: you approve or edit suggestions alongside preset checks. The agent never runs checks or saves anything itself.
• Run and track: checks run against the data, and results are kept as history with drift over time.
• Cache: suggestions are cached in Postgres keyed by a hash of schema + sample, so a repeat call returns in ~40ms instead of ~4s without re-hitting the API.

Architecture

A FastAPI backend with Postgres, a React + TypeScript frontend, and a single Docker service in production: FastAPI serves the built frontend from the same origin, and uploaded files live in Supabase Storage so they survive free-tier restarts.

The problem

Clickstream data arrives as a continuous stream of small events. This project builds a fully serverless pipeline on AWS that simulates that stream, lands it, transforms it and makes it queryable, with orchestration and alerting around it.

Pipeline

Lambda (simulate events)
  → Kinesis stream
  → Lambda (read stream, write raw JSON to S3)
  → Step Functions
      → Glue ETL (flatten geo fields, convert timestamps, partition by date)
      → Athena (MSCK REPAIR TABLE)
      → SNS (success / failure)

Services

• Kinesis for real-time ingestion
• Lambda, twice: one simulates events with faker, one reads from Kinesis and writes to S3
• S3 for the raw and processed zones
• Glue for cleaning and date partitioning
• Athena to repair partition metadata and query the processed data
• Step Functions to orchestrate the run, with SNS notifications on success or failure

The problem

Predict how much power a solar plant in Phoenix, Arizona generates each day from the weather alone, and see whether automated feature selection beats simply using every feature.

Data

• Daily weather (temperature, humidity, wind, solar radiation) for 2006 from the NASA POWER API.
• Hours of daylight for the site, computed with pvlib.
• Five-minute plant output from NREL, summed per day as the target.

Modelling

Three regression models, evaluated on the same 10% hold-out (37 days):

Model	R²	Avg. error
Linear regression, all features	0.825	9.3%
Polynomial (degree 2)	0.750	12.8%
Linear after RFECV feature selection	0.702	15.8%

Feature selection made things worse here: with only five weather features there was little noise to remove, and dropping any of them cost signal. A random-forest importance check agreed: solar radiation carries most of the signal (≈0.74), with daylight hours a distant second (≈0.12).

The problem

Job boards return far more postings than anyone can read. This is a personal agent that fetches postings, filters them against my profiles, and has Claude score and rank the shortlist.

How it works

• Fetch from the Adzuna API, with the country as a parameter and a configurable posting-age window applied server-side.
• Search several keyword profiles independently, in a fixed priority order (Data Engineering first), so cross-profile duplicates resolve predictably.
• Remember what’s already been seen in SQLite, keyed globally by job link, so each run only surfaces new postings.
• Score each profile’s shortlist with one batched Claude call per run rather than one call per job, to keep token usage down.
• Track results in a persistent Excel tracker that accumulates rows across runs, with an editable “Applied” column.