Work / Web app · 2026

Optimal Lab

Optimal Lab teaches engineering concepts through interactive visuals that learners drag, step through and break. I co-founded it with Muhammad Sarmad, who built the site shell and analytics; I build the sessions and the simulation models behind them, across system design, AI, DevOps, frontend, databases, AI-native products, automation and tools. Each topic goes in as its own pull request, and my System Design and AI sessions have been merged.

  • case study
  • co-founded
  • web app
Type
Web app · Interactive engineering education
Built with
TypeScript, React, Next.js
Also uses
Tailwind CSS, Motion, Supabase
Last active
2026

Overview

Optimal Lab explains engineering through one interactive visual per concept: learners drag, step through and break things to see how they work, and DSA practice problems link back to the sessions that teach them.

I co-founded it with Muhammad Sarmad.

Context and problem

The site seems aimed at developers and students learning engineering concepts, and its premise is that a mechanism is easier to grasp when you can change its inputs and watch what happens than when you only read about it.

My role

I describe my part from my commits and pull requests only. Sarmad built and runs the site shell: the home and track pages, the practice section, the header, the shared session components and the Supabase analytics.

I build the interactive sessions and the TypeScript models behind them, in src/sessions and src/lib, across eight tracks: System Design, AI, DevOps, Frontend, Databases, AI Native, AI Automation and Tools.

Each topic goes on its own branch and reaches the upstream repository as a pull request, which Sarmad merges.

Solution and user experience

A session either walks through a concept step by step or shows it as a system map with animated packets, and choice controls let the learner swap a design decision and see what changes.

Behind each demo sits a deterministic model in src/lib, so the same choices always produce the same trace, costs and outcome.

Key features

The System Design and AI tracks are merged upstream; the other tracks were submitted as pull requests that were still open on 2026-10-25.

  • System Design: sessions and case studies on a URL shortener, rate limiter, chat, news feed, payments and ledgers, a web crawler, a coding agent, agent memory and state machines, guardrails, prompt injection, access control, ADRs and capacity planning.
  • AI: embeddings, transformer blocks, pretraining, RLHF, few-shot prompting, chain of thought, GraphRAG, reasoning models, computer use and red-teaming.
  • DevOps: Linux and networking, Git and CI/CD, containers, Kubernetes, infrastructure as code, cloud, observability and SRE, DevSecOps, platform engineering and case studies.
  • AI Native, AI Automation and Tools: AI product UX, shipping and developer workflow; workflow automation with people in the loop; coding agents, protocols, model APIs, retrieval tools and LLMOps.
  • Frontend: DOM parsing and reflows, server components and Suspense, state, streaming SSR and islands, PWAs and accessibility, bundlers and testing.
  • Databases: ACID and locking, crash recovery and point-in-time recovery, caching and Redis internals, wide-column, graph, inverted-index and HNSW structures, and migration and ORM pitfalls.

Architecture and stack

Sarmad's Next.js shell hosts every session through a registry in src/sessions/registry.tsx; each of my sessions is a React client component paired with a model in src/lib.

  • Sessions: TypeScript and React 19 client components that follow the shell's Next.js App Router conventions and reuse its shared session components.
  • Models: pure TypeScript simulation and cost models, such as codingAgent.ts, paymentsLedger.ts and realWorldTools.ts.
  • Around my work: the repository also uses Next.js 16, Tailwind 4, Motion and Supabase JS; the analytics routes and migrations are Sarmad's.

Implementation details

One commit added four System Design case studies, each a demo plus a model: a web crawler (robots.txt, URL normalization, one queue against a queue per host, content fingerprints and a Bloom filter for seen URLs), a payment system that has to charge exactly once through a double click, a provider timeout and a crash, a document assistant (permission-aware sync, vector index sizing, retrieval filtered by the asker, citation checks and cost per question) and a coding agent.

The coding-agent model traces one agent run that fixes a failing date-parsing test, under four choices: the whole repository in the prompt or map, search and read; a sandbox; running the tests until they pass; and approval before risky actions. A curl | sh line planted in a vendor README runs on the developer's machine unless the run is sandboxed or needs approval, and the cost comes from resending the whole conversation at every step.

I also restructured System Design to link 21 topics that other tracks already cover, instead of listing them again as "coming soon".

Challenges

  • The hard part is turning abstract topics, such as agent memory, payment ledgers, Kubernetes or HNSW indexes, into models that a learner can step through and break on purpose.

Trade-offs

Keeping every model deterministic and in the browser likely makes each demo reproducible without a backend, at the cost of simplifying how the real systems behave.

Screenshots

These captures show the homepage, which is part of Sarmad's shell; my work is in the sessions it links to.

Skills demonstrated

  • Interactive UI in React and TypeScript.
  • Simulation and cost modelling in TypeScript.
  • Explaining system design, AI and DevOps through working models.
  • Pull-request-based collaboration with a co-founder.
All projects →