# Build brief — a focused alternative to LeetCode

> **Verdict:** Not faithfully · **Buildability:** 9/100 · **Category:** Career
> **Source:** https://www.canitbevibecoded.com/leetcode
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from LeetCode. Verify current pricing and capabilities before acting.

## Context

**LeetCode** — A graded problem bank and judge for practicing coding interviews, plus company-tagged questions and editorials behind a paid tier. It currently costs $35/mo.

An agent can produce a Monaco editor, a problem list, a submissions table and a Judge0 sandbox in a session, and none of that is the product. LeetCode is a content and coordination asset: thousands of curated problems with hidden test cases that actually catch off-by-one and TLE, editorials, company frequency tags, and the social fact that interviewers pull questions from it, which you cannot self-host. Clone the harness and you sit staring at an empty problems directory; authoring good problems with adversarial test cases is the actual job. Build the trainer if you want a private drill rig over problems you have already seen, but do not pretend it replaces the bank.

This brief describes a focused, single-operator replacement for the part of LeetCode that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

A local judge that runs your submitted Python or JavaScript against test cases in Docker, stores every attempt, and resurfaces solved problems on a spaced repetition schedule.

- Tailor resumes, track applications, and rehearse answers from your own history.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Docker installed and a willingness to trust your own container flags with untrusted code.
- Your own problem statements and test cases, written by hand or from openly licensed sets.
- Python 3.11 and Node for the app itself.
- Time budget for the boring part: authoring adversarial test cases, not the UI.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a local coding interview trainer. One repo, single user, no accounts, no cloud, no telemetry. It runs on my machine.

Stack, not negotiable: Python 3.11 with FastAPI on the backend, SQLite through SQLAlchemy, a Vite + React + TypeScript frontend using the Monaco editor, Docker for code execution. Do not add auth. Do not add a hosted judge API.

Problems live on disk, not in the database. Each problem is a folder under ./problems/<slug>/ containing problem.md (the statement), meta.yaml (title, difficulty, topic tags, language stubs) and tests.json (an array of {input, expected} objects, including at least one large case for timing). Write 12 seed problems yourself covering arrays, two pointers, a stack, binary search, BFS on a grid, interval merging, and one small DP. Do not scrape or reproduce LeetCode content.

Execution: POST /api/run accepts {slug, language, code} and runs it in a throwaway Docker container. Only python:3.11-slim and node:20-slim images. Flags: --network none, --memory 256m, --cpus 0.5, --pids-limit 64, read-only root filesystem, non-root user, 5 second wall clock kill. Wrap the submitted function with a harness that feeds each test case and compares output. Return per-test pass or fail, stderr, and runtime in milliseconds. Never execute submitted code outside Docker, not even in dev mode, not even as a fallback.

Store every submission in SQLite: slug, language, code, verdict, runtime, timestamp. I want to diff my third attempt against my first.

Review queue: SM-2 style spaced repetition over solved problems. Correct solve pushes the next due date out, a failure resets it. GET /api/due feeds a Today view that tells me what to redo.

UI, three routes: problem list with difficulty, last verdict and next due date · problem view with statement left, Monaco right, Ctrl+Enter to run, results panel below · stats page with a solve calendar and per-topic pass rate.

Explicitly out of scope: contests, leaderboards, other people's solutions, discussion threads, company tags, languages beyond Python and JavaScript, mobile layout, deployment.

Ship a README with a single make dev command and a .env holding only PORT and DOCKER_HOST. Before you claim it works, prove the sandbox survives an infinite loop, a fork bomb, a 2 GB allocation, and an outbound HTTP request, and paste the output.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- The problem bank itself, thousands of problems with hidden tests tuned to catch the specific ways people get it wrong.
- Company tags and frequency data, which is the main reason people pay for Premium.
- Editorials and the discussion threads where the actual learning happens.
- Contests, ratings, and the mild public humiliation that makes you keep showing up.
- Any signal that you are practicing the same questions your interviewer will ask.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/leetcode