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.tsandrealWorldTools.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.
Links
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.
