Nischal Singh Bista B.S. Computer Science, UW–Madison ’27 P. 001 / 084
Full-Stack · Serverless · Applied Machine Learning Madison, Wisconsin

Full-stack products, serverless backends, and applied machine learning. Six spreads follow; the tradeoffs are printed honestly.

Ed. I — Open to SWE Internships
Table of Contents 84 pp. — set & printed in the browser Begin ↓

Works

Six spreads — the problem, the architecture, the tradeoffs. Scroll; the press turns the page.

Spread 01 — The Daily Fit — A Wordle for Wardrobes, Scored by Vector Search

Work 01 · Capstone — Amazon Shopbop · Serverless · Sep 2026 – Present

The Daily Fit

A Wordle-style fashion puzzle, scored by semantic similarity.

§1 The Problem

Shopbop sells fashion; the capstone brief asked for a daily habit to match — a guessing game where the score isn’t letter colours but closeness of taste. Judging “semantically similar” between outfits is exactly the kind of problem humans argue about and vector search doesn’t. It also had to persist streaks, or a daily game is just a page refresh away from forgetting you existed.

§2 The Architecture

A web client talks to a serverless AWS spine: API Gateway fronts Lambda functions that generate the daily puzzle, score every guess through Shopbop’s vector search API, and persist puzzles, guesses, and streaks in DynamoDB. No servers, no schedules to babysit — the game is data, and the data is small.

§3 The Tradeoffs

Serverless is the right tradeoff because the load is a daily spike, not a stream — cold starts matter less than a zero-ops bill. One DynamoDB table holds puzzles, guesses, and streaks; denormalizing around known access patterns beat a relational schema for this. And the similarity judge lives in Shopbop’s own vector search API, which means we inherit their notion of style — for a fashion product, that is the correct dependency to have.

Shopbop.com ↗

Serverless earns its keep here because the traffic is a daily spike, not a stream. A game that resets every day doesn’t need a fleet — it needs one table that never lies about a streak.
GUESS SCORE PUT THE JUDGE SERVERS MANAGED: 0 ONE TABLE · KNOWN ACCESS PATTERNS WEB CLIENTDAILY CADENCE API GATEWAYHTTPS · REST LAMBDASCORE · PERSIST DYNAMODBGUESSES · STREAKS VECTOR SEARCHSEMANTIC SIMILARITY
Fig. 01 — Request path. The judge is a vector search API.
0servers to manage
1DynamoDB table, three access patterns
24hpuzzle rotation
AWS LAMBDAAPI GATEWAY DYNAMODBREACT VECTOR SEARCHSEMANTIC SIMILARITY SERVERLESSREST

Stack — drag the strip to scrub

Spread 01 — pp. 12–21
Spread 02 — Trail Lab — PDF Q&A and Multilingual Audio Pipelines

Work 02 · Internship — Trail Lab · Applied AI · Sep 2025 – Present

Trail Lab

PDF question-answering and multilingual audio, at conversation speed.

§1 The Problem

Trail Lab’s knowledge lives in PDFs and recordings — papers, field notes, interviews. Search finds documents; it doesn’t answer questions. And every change waited on a fifteen-minute deploy, which is how CI quietly becomes a tax on shipping anything at all.

§2 The Architecture

Two FastAPI pipelines under one Next.js front end. PDFs are chunked, embedded, and stored so retrieval returns context in under 0.2 seconds, with Groq models doing the answering. Audio runs through Groq for transcription, summarization, and translation across 10+ languages. CI/CD moved to GitHub Actions with GCP Cloud Build, gated by test suites.

§3 The Tradeoffs

Groq-hosted inference trades control for speed — I’d rather tune retrieval than babysit GPUs. The 0.2-second budget shaped the architecture more than any model choice: embeddings are precomputed and the retriever stays deliberately simple. And the deploy went from fifteen minutes to two, which changed behaviour more than any feature — fast CI actually gets run.

Internal — Trail Lab, Madison WI

The 0.2-second budget is a product decision, not a benchmark. Answers that arrive late feel wrong even when they’re right, so the embeddings are precomputed and the retriever is allowed to be boring.
RETRIEVAL ≤ 0.2 S DEPLOY: 15 TO 2 MIN FASTAPI · NEXT.JS CLIENT PDF Q&AUPLOADS CHUNK EMBED VECTOR STOREPRECOMPUTED GROQ LLMANSWERS AUDIORECORDINGS GROQ · STTTRANSCRIBE SUMMARIZETRANSLATE · 10+ LANG
Fig. 02 — Two pipelines, one budget: retrieval under 0.2 s.
0.2scontext retrieval
10+languages translated
2mindeploys, was 15
FASTAPINEXT.JS GROQEMBEDDINGS PYTHONTYPESCRIPT GITHUB ACTIONSGCP CLOUD BUILD

Stack — drag the strip to scrub

Spread 02 — pp. 22–30
Spread 03 — Badger Code — A Coding Agent, Graded on 89 Tasks

Work 03 · Agents & Evaluation · Terminal-Bench · Ongoing

Badger Code

A Qwen coding agent, graded honestly on 89 terminal tasks.

§1 The Problem

Coding agents fail in ways that are hard to see and harder to reproduce. The question was never whether Qwen could write code — it was how often it could finish a real terminal task, in a sandbox it can’t escape, measured the same way every single time.

§2 The Architecture

A Qwen-powered coding agent runs autonomous shell workflows through Harbor, each attempt inside its own isolated Docker environment. A reproducible Terminal-Bench pipeline evaluates across 89 tasks, tracking every action the agent takes and scoring completion honestly: 40+ of 89 finished end-to-end.

§3 The Tradeoffs

Isolation is expensive — a container per attempt is slower than sharing a machine — but it’s the only configuration where a benchmark means anything. Terminal-Bench over a custom suite, because a standard everyone can check beats a leaderboard only I can verify. And the failures are kept, not hidden; the unfinished tasks are the interesting part.

GitHub ↗

A container per attempt is the whole trick: slow to provision, impossible to cheat, and every run replays the same way. Reproducibility is a feature you pay for in seconds.
SHELL ACTIONS · OBSERVE RUN EXEC GRADE A CONTAINER PER ATTEMPT TASKSTERMINAL-BENCH · 89 AGENTQWEN · HARBOR DOCKER SANDBOXISOLATED PER RUN RESULTSLOGGED · SCORED 40+ / 89COMPLETED
Fig. 03 — Agent loop. Every attempt replays the same way.
89tasks evaluated
40+completed autonomously
1container per attempt
PYTHONQWEN HARBORTERMINAL-BENCH DOCKERSHELL WORKFLOWS EVALUATIONREPRODUCIBILITY

Stack — drag the strip to scrub

Spread 03 — pp. 31–39
Spread 04 — MERRA-2 — Atmospheric Machine Learning, UW AOS

Work 04 · Research — UW–Madison AOS · Machine Learning · May–Aug 2025

MERRA-2

Five hundred gigabytes of atmosphere, taught to behave.

§1 The Problem

The Department of Atmospheric & Oceanic Sciences sat on 500GB+ of NASA MERRA-2 reanalysis data and a stack of ensemble models that were neither fast nor consistently accurate. Analysis was manual, and experiment workflows varied by whoever happened to run them.

§2 The Architecture

Feature engineering and ensemble optimization in Python — Pandas and NumPy for the heavy lifting, scikit-learn for the models — with automated processing and visualization pipelines replacing the manual loop. Cross-validation was formalized so every experiment is comparable. Accuracy improved 15%; manual analysis time halved.

§3 The Tradeoffs

Ensembles over deep networks: the data is wide, tabular, and expensive to move, so the wins came from features and validation rather than architecture heroics. scikit-learn over PyTorch here is a deliberate downgrade in fashion and an upgrade in honesty — every result cross-checked, every pipeline reproducible by the next student in the lab.

UW AOS ↗

At 500GB, IO dominates everything: the pipeline preprocesses once and caches features, because recomputing them is the most expensive sentence in the codebase.
ACCURACY +15% ANALYSIS TIME −50% REPRODUCIBLE BY THE NEXT STUDENT MERRA-2NASA · 500 GB+ FEATURESPANDAS · NUMPY ENSEMBLESSCIKIT-LEARN CROSS-VALK-FOLD DASHBOARDSLAB VIZ
Fig. 04 — Research pipeline. Every experiment cross-checked.
500GB+NASA data, processed
15%accuracy, up
50%manual analysis, cut
PYTHONPANDAS NUMPYSCIKIT-LEARN NASA MERRA-2ENSEMBLES CROSS-VALIDATIONVISUALIZATION

Stack — drag the strip to scrub

Spread 04 — pp. 40–48
Spread 05 — Educate Nepal — A Non-Profit Platform on AWS

Work 05 · Non-Profit — Educate Nepal Initiative · Full-Stack · Live

Educate Nepal

A non-profit platform, ten thousand readers strong.

§1 The Problem

The Educate Nepal Initiative needed a real platform — 10K+ monthly users, authentication, content, a database that doesn’t fall over on the day it matters — with a non-profit budget and a volunteer engineering team of one.

§2 The Architecture

A three-tier platform: React + TypeScript front end, Node.js APIs, PostgreSQL — on AWS. I owned the database design, authentication, backend APIs, and cloud deployment end to end, schema to DNS, and architected it to stay legible to whoever maintains it after me.

§3 The Tradeoffs

One volunteer owning the whole stack isn’t good architecture on paper; it’s what a volunteer budget buys, and it holds up at ten thousand readers a month. Postgres over a managed PaaS database kept costs near zero and the schema auditable. AWS over shared hosting, because a non-profit’s worst outcome is being down on the day it matters.

Repository ↗

Every layer chosen to be boring on purpose: relational data, stateless APIs, one cloud. The interesting decisions were the schema and the auth flow — everything else is plumbing that stays out of the way.
HTTPS REST SQL AWS END-TO-END: SCHEMA TO DEPLOY USERS10K+ MONTHLY REACT + TSFRONT END NODE.JS APISAUTH · REST POSTGRESQLSCHEMA OWNED
Fig. 05 — Three tiers on AWS. One owner, zero budget, 10K users.
10K+monthly users
100%owned, schema to deploy
3tiers on AWS
REACTTYPESCRIPT NODE.JSPOSTGRESQL AWSAUTHENTICATION REST APISNON-PROFIT

Stack — drag the strip to scrub

Spread 05 — pp. 49–57
Spread 06 — BadgerRides — Real-Time Carpooling for UW–Madison

Work 06 · Full-Stack Product · Real-Time · Shipped

BadgerRides

Ride matching for Badgers, with a chat that keeps up.

§1 The Problem

UW–Madison students coordinate carpools in group chats: rides buried under memes, no matching, no record of who’s going where. BadgerRides gives the campus a purpose-built platform — ride matching, profiles, and a chat that behaves like chat should.

§2 The Architecture

A React + TypeScript client over a Node.js/Express REST API, PostgreSQL as the source of truth, JWT for stateless authentication, and Socket.IO for real-time messaging — each ride is a room, and every message is scoped to the carpool you’re actually in.

§3 The Tradeoffs

Socket.IO over polling trades connection management for an interface that feels live — the right tradeoff for chat, the wrong one for anything a user can afford to refresh. JWT keeps the servers stateless and horizontal scaling boring. Ride matching lives server-side, where it can be tested, not in the client, where it can be faked.

Repository ↗

Rooms per ride keep the chat scoped: you only hear the carpool you joined. JWT keeps the server stateless; Postgres keeps the truth. Everything else is an optimization.
ONE ROOM PER RIDE PERSIST JWT AT THE GATE RIDER A RIDER B SOCKET.IONODE · EXPRESS · JWT POSTGRESQLRIDES · MESSAGES
Fig. 06 — Rooms, not refreshes. Scope is the security model.
RTSocket.IO live messaging
JWTstateless auth end to end
RESTAPI backbone, Express
REACTTYPESCRIPT NODE.JSEXPRESS POSTGRESQLSOCKET.IO JWTREST

Stack — drag the strip to scrub

Spread 06 — pp. 58–71
Spread 01 / 06 — THE DAILY FIT

Research & Honors

The lab work, the honors list, and the syllabus. No conference talks yet — the press is warmed up for the first one.

Plate 07 — Frontispiece

500GB+ of atmosphere,
modeled, validated,
reproducible.

Dept. of Atmospheric & Oceanic Sciences UW–Madison May – Aug 2025
Frontispiece — research plate. The full index, below.

Research & Lab Work

Optimized ensemble models and engineered features on 500GB+ of NASA MERRA-2 data, improving accuracy by 15%. Built automated processing and visualization pipelines that cut manual analysis time by half, and formalized reproducible workflows with cross-validation across the lab.

Spread 04 ↓

A daily Wordle-style fashion guessing game scored by semantic similarity via Shopbop’s vector search API, on a serverless AWS backend — Lambda, API Gateway, DynamoDB — persisting puzzles, guesses, and streaks.

Spread 01 ↓

FastAPI + Next.js pipelines over Groq APIs: document question-answering with context retrieved in under 0.2 seconds, and audio transcription, summarization, and translation across 10+ languages. CI/CD on GitHub Actions and GCP Cloud Build, deploys from 15 minutes to 2.

Spread 02 ↓

Honors & Awards

A full-ride scholarship to the University of Wisconsin–Madison, funding the degree through May 2027.

Placed in the Department of Atmospheric & Oceanic Sciences, May–Aug 2025 — see Spread 04.

Scholar designation for STEM students in the College of Letters & Science.

Semester honors for academic distinction. GPA 3.6, minor in Data Science.

Syllabus — Selected Coursework

Distributed SystemsDocker
Deep Learning & Generative ModelsPyTorch
Database Management SystemsSQL
Operating SystemsCore
Data Structures & AlgorithmsCore
ProbabilityStatistics
Object-Oriented ProgrammingJava
MinorData Science

Contact & Colophon

Correspondence answered within one business day, usually faster.

Put something
on paper.

NISCHALSINGHBISTA@GMAIL.COM +1 (608) 722-0825

Open to software engineering internships — Summer 2027 — and new-grad roles from May 2027. If your problem involves pipelines, PDFs, or a stubborn model, I already have opinions.

GitHub ↗ LinkedIn ↗ www.n1-sb.com ↗ Résumé ↗
Type & Ink

Set in Bricolage Grotesque for display, Newsreader for text, and Space Mono for anything that smells like data. One colour of ink — #DF3D10 — on #F3EFE6 uncoated stock. The cursor leaves risograph dots because real presses never register perfectly, and neither should this page.

Education

B.S. Computer Science, minor in Data Science — University of Wisconsin–Madison, expected May 2027 · GPA 3.6. King Morgridge Scholar (full ride), Dean’s List, L&S STEM Scholar, Undergraduate Research Scholar.

Edition

First edition. A single HTML file: no framework, no build step, no analytics, no cookies. Reduced-motion readers get a still press.

© Nischal Singh Bista — set & printed in the browser n1-sb.com Back to cover ↑