Projects

A coding platform that safely runs untrusted code and grades it in the background.

Problem. User code can be malicious or loop forever. It has to run safely, and grading must not block the API.

How it works. Express API stores the submission and puts it on a BullMQ queue, so it returns instantly. Workers run the code in Docker and save results to PostgreSQL (Drizzle). Problem files live in S3.

• Each submission runs in an isolated Docker container with no network, a read-only filesystem, and CPU, memory and time limits. This contains infinite loops, fork bombs and network calls.
• Grading runs on BullMQ workers, so the API never waits on it.
• All of a submission's test cases run in one reused container, and grading stops at the first failure.

Ask questions about your PDFs and get answers grounded in the document.

Problem. Simple RAG loses context: chunks cut sections in half, follow-up questions retrieve the wrong parts, and weak matches waste the token budget.

How it works. Next.js app with Azure OpenAI for answers and embeddings, Pinecone for vector search, PostgreSQL (Drizzle) for chat history, and Vercel Blob for uploaded PDFs.

• Documents are split into section-aware chunks, so headings and bullets stay together.
• Search only looks at the active document's vectors.
• Follow-up questions are rewritten from chat history before retrieval.
• Retrieved chunks are ranked by score, weak and duplicate matches are dropped, and the best are packed into a fixed token budget.
• Chunking and retrieval settings were tuned across 100+ configurations.

A browser IDE like Replit. Each project runs in its own container with a terminal, file editor, app preview and database browser.

Problem. User code has to run somewhere isolated. Every project needs its own runtime, files and terminal, kept off the main servers.

How it works. FastAPI services for auth and metadata, an orchestrator that starts a Kubernetes container per project on demand, and a small runner inside each one. Files are stored in S3, metadata in PostgreSQL.

• Every file is stored once by its content hash, so identical files across projects are never duplicated. A scheduled garbage collector deletes files nothing points to.
• Each project gets its own on-demand Kubernetes container, keeping user code off the main servers.
• The runner streams a live terminal over WebSockets and serves the file editor, app preview and database browser.

Finds job listings, tailors resume bullets to each one, and applies automatically. I used it for my own job search.

Problem. Applying to many roles by hand is slow, and AI rewrites can invent skills you do not have.

How it works. Collection, AI processing and browser automation run as separate BullMQ queues, so a block in one stage does not stall the others.

• Pulls listings from LinkedIn, Wellfound, YC Work at a Startup and Telegram.
• A validator rejects any rewritten bullet that mentions a skill not in my real profile.
• Duplicate listings across sources are removed by hashing title, company and description.

Upload a PDF and watch each processing stage happen live.

Problem. Heavy PDF extraction inside a request causes timeouts, and users wait without knowing what is happening.

How it works. FastAPI takes the upload, Celery workers do the extraction, and Redis Pub/Sub sends progress to the Next.js client over WebSockets.

• All extraction runs outside the request.
• Users see parse, extract and save stages as they happen.

A real-time chat app built to handle many messages at once.

Problem. Writing every message straight to the database becomes a bottleneck under heavy traffic.

How it works. Socket.io servers publish messages to Kafka. Workers batch-write them to PostgreSQL, and Redis Pub/Sub shares events across servers.

• Kafka separates receiving messages from saving them.
• Users connected to different servers can still share a room.

A shared whiteboard where several people draw on the same canvas live.

How it works. Next.js and Canvas on the frontend, a REST API and a separate WebSocket server, PostgreSQL with Prisma, in a Turborepo monorepo.

• HTTP and WebSocket servers are separate, so they scale on their own.
• Shared database schema and UI code live in one monorepo.

Peer-to-peer video calls in the browser, with a Node.js signaling server.

• Video and audio go directly between browsers over WebRTC.
• A WebSocket server exchanges the connection details and manages rooms.

Backend for a course marketplace with user, creator and admin roles.

• Purchases move through PENDING, SUCCESS and FAILED states.
• Database constraints block duplicate purchases.