PROJECT LAB · 13 VERIFIED BUILDS

Build projects that prove what you understand.

A project is complete when another person can reproduce it and its acceptance checks pass—not when the code merely looks finished. Choose the smallest project that stretches one skill beyond your current course.

Find a project

Showing all 13 projects

01 · BEGINNER · CLI

Command-line unit converter

Convert temperatures and distances through explicit units, validated input, predictable rounding, and useful failure messages.

System boundary

The program receives a source unit, target unit, and numeric text from command-line arguments. It writes one converted value to standard output or one safe diagnostic to standard error and returns a documented exit status.

Milestones

  1. Write a conversion table and units before code.
  2. Parse one complete input without accepting trailing text.
  3. Separate conversion math from command-line formatting.
  4. Add help output and classified invalid-input failures.

Acceptance checks

  • Known examples and inverse conversions agree within the declared rounding rule.
  • Zero, negative values, decimals, and exact boundaries are tested.
  • Unknown units, missing arguments, and nonnumeric input return nonzero.
  • The README records runtime version, commands, and expected output.
  • A second person can add one unit without changing the parser.

Extend it

Add data-size units with base-10 versus base-2 policy, then explain why a universal conversion formula would be misleading.

02 · BEGINNER · FILES

Text evidence analyzer

Read a UTF-8 file and report lines, words, frequent terms, and the locations of malformed or policy-breaking records.

PrerequisitesFoundationsPython

System boundary

The source file is evidence and remains unchanged. The analyzer receives its path and optional limits, decodes under an explicit policy, and writes a deterministic report to a separate destination.

Milestones

  1. Hash and inspect a tiny fixture before parsing.
  2. Define “line,” “word,” case normalization, and punctuation policy.
  3. Stream records under maximum byte and line limits.
  4. Sort equal counts with a deterministic tie breaker.

Acceptance checks

  • Empty, one-line, multiline, Unicode, and invalid-byte fixtures are covered.
  • Repeated runs over identical bytes produce identical reports.
  • The source is not modified after success or failure.
  • Counts reconcile with accepted and rejected records.
  • Diagnostics identify location without dumping private content.

Extend it

Compare byte, code-point, and user-perceived character counts, then document which one each product requirement needs.

03 · BEGINNER · WEB

Accessible knowledge page

Publish a small subject guide whose structure, navigation, forms, media, and responsive layout work without relying on visual appearance alone.

PrerequisitesHTMLCSS

System boundary

The page contains an article, table of contents, comparison table, image with meaningful alternative text, and feedback form that performs client-side constraint feedback without pretending to submit data.

Milestones

  1. Write the heading outline and landmark structure first.
  2. Make every interaction work with keyboard and native elements.
  3. Add a narrow-first layout without fixed content heights.
  4. Test zoom, large text, reduced motion, and forced colors.

Acceptance checks

  • Heading order communicates the same hierarchy as the visual design.
  • Every control has a programmatic name and visible focus.
  • The page has no horizontal scrolling at 320 CSS pixels.
  • Form errors identify the field and correction without color alone.
  • CSS-disabled content remains readable in source order.

Extend it

Add a disclosure-based glossary and print stylesheet while preserving reading order and link meaning.

04 · APPLIED · BROWSER

Browser study tracker

Build an offline-capable tracker with explicit state transitions, durable local data, undo, filtering, and accessible interaction.

System boundary

A learner creates study items, records sessions, changes status, filters the list, and reloads without losing validated state. No account or remote synchronization is implied.

Milestones

  1. Model states and allowed events before DOM work.
  2. Write pure transitions and serialize a versioned document.
  3. Render from state with stable identifiers and focus policy.
  4. Add undo and migration from one older schema version.

Acceptance checks

  • Reload reproduces the last committed state exactly.
  • Malformed stored data fails safely and does not execute code.
  • Keyboard users can create, edit, filter, undo, and delete.
  • Repeated events and empty collections have defined outcomes.
  • Transition tests run without a browser DOM.

Extend it

Add export and import with preview, duplicate resolution, and an atomic replace-or-merge decision.

05 · APPLIED · API

Reading-list API

Design a small HTTP service with stable resources, validation, authorization boundaries, database transactions, and observable errors.

System boundary

Clients create lists, add books, record progress, and retrieve a paginated view. The service owns list state and never trusts client-supplied ownership, completion totals, or database identifiers.

Milestones

  1. Write resource and error contracts as request/response examples.
  2. Create schema constraints and transaction boundaries.
  3. Implement authorization for every resource lookup and write.
  4. Add structured logs, request IDs, health, and readiness.

Acceptance checks

  • Malformed input, missing resources, conflicts, and forbidden access have distinct outcomes.
  • Repeated idempotent requests cannot duplicate state.
  • Pagination has stable ordering and tie breaking.
  • Concurrent updates cannot silently lose progress.
  • Integration tests start from an empty isolated database.

Extend it

Add an outbox event for completed books and prove that a retry cannot publish a logical event twice.

06 · APPLIED · DATABASE

Transactional enrollment ledger

Model learners, courses, seats, enrollments, payments, and audit events under constraints that survive concurrent writes.

System boundary

The database is the authority for enrollment state. Every accepted enrollment occupies at most one seat, every payment belongs to one enrollment, and every state transition leaves traceable evidence.

Milestones

  1. Draw entities, identities, relationships, and invariants.
  2. Encode shape and uniqueness with schema constraints.
  3. Write a transaction for enroll, cancel, and waitlist promotion.
  4. Measure query plans for roster and learner-history views.

Acceptance checks

  • Two concurrent requests cannot oversubscribe the last seat.
  • Cancel plus promotion is atomic under the stated isolation level.
  • Foreign keys prevent orphaned payments and events.
  • Migration forward and rollback are rehearsed on fixture data.
  • Backup restore reproduces row counts and ledger totals.

Extend it

Add course prerequisites and explain which rule belongs in a constraint, transaction, or application policy.

07 · ADVANCED · DATA

Replayable data-quality pipeline

Ingest versioned files, validate records, quarantine failures, produce aggregates, and publish only after reconciliation succeeds.

System boundary

Immutable input snapshots enter a bounded pipeline. Accepted, rejected, and intentionally ignored records reconcile to the source. A failed run cannot replace the last verified output.

Milestones

  1. Define a versioned data contract and fixture manifest.
  2. Separate decode, parse, validate, deduplicate, and transform.
  3. Write staged output plus reconciliation assertions.
  4. Publish atomically with lineage and artifact hashes.

Acceptance checks

  • Input count equals accepted plus rejected plus ignored.
  • Repeated runs over the same snapshot are deterministic.
  • Restart after interruption does not duplicate accepted records.
  • Schema changes are accepted or rejected by explicit version policy.
  • Every output record traces to source snapshot and transform version.

Extend it

Add late-arriving corrections and compare overwrite, append-only, and bitemporal history designs under replay, audit, deletion, and reporting requirements.

08 · ADVANCED · CONCURRENCY

Concurrent endpoint health checker

Probe many endpoints under deadlines, bounded concurrency, cancellation, classified outcomes, and deterministic reporting.

System boundary

The checker receives a bounded endpoint manifest and emits one result per endpoint. It controls DNS, connection, TLS, response, body, retry, and total deadlines without leaking response secrets.

Milestones

  1. Implement a correct sequential probe with typed outcomes.
  2. Add a worker or task limit and total cancellation.
  3. Preserve stable output ordering independent of completion order.
  4. Expose latency distributions and resource saturation.

Acceptance checks

  • Every input produces exactly one terminal result.
  • Concurrency never exceeds the configured bound.
  • Cancellation closes response bodies, tasks, timers, and sockets.
  • Timeout, DNS, TLS, HTTP, and content failures remain distinct.
  • A slow endpoint cannot block completed results indefinitely.

Extend it

Add bounded retries with jitter and prove the total deadline and request budget remain enforced.

09 · ADVANCED · SECURITY

Secure document service

Upload, authorize, scan, store, retrieve, audit, expire, and delete untrusted documents without treating filenames or MIME claims as truth.

System boundary

Untrusted bytes cross a size-limited streaming boundary into quarantine under an authenticated tenant and request identity. Only scanned, policy-approved objects become retrievable through authorization-checked opaque identifiers, while rejected or interrupted objects are removed safely.

Milestones

  1. Write a threat model and abuse-case table.
  2. Stream to quarantine with limits, hash, and safe metadata.
  3. Separate scanner result from publication transaction.
  4. Add audit, retention, deletion, and incident controls.

Acceptance checks

  • Paths, content type, extension, and user filenames cannot choose storage authority.
  • Unauthorized users cannot infer object existence.
  • Oversized, interrupted, malicious, and duplicate uploads clean up safely.
  • Logs contain stable event IDs without document content or secrets.
  • Key rotation, restore, and emergency quarantine are rehearsed.

Extend it

Add tenant-specific retention and legal hold while proving ordinary deletion cannot remove protected evidence.

10 · ADVANCED · AI

Citation-grounded RAG evaluator

Build a retrieval and answer-evaluation harness that measures evidence selection, citation support, refusal, latency, and cost.

System boundary

A versioned corpus and question set enter the harness. Retrieval results, prompt context, model output, citations, evaluator decisions, cost, and latency remain traceable to configuration and artifact versions.

Milestones

  1. Create answerable, unanswerable, conflicting, and injection cases.
  2. Measure retrieval recall before generation quality.
  3. Check whether each claim is entailed by cited evidence.
  4. Compare against no-retrieval and simple-search baselines.

Acceptance checks

  • Unauthorized documents are filtered before retrieval and generation.
  • Missing evidence produces refusal rather than invented support.
  • Aggregate scores retain per-case failures and evaluator rationale.
  • Runs record corpus, model, prompt, seed where supported, and cost.
  • A regression threshold blocks a worse candidate from promotion.

Extend it

Add adversarial documents that instruct the model to ignore policy, then separate retrieval defense, prompt defense, and output enforcement evidence.

11 · BEGINNER · DATA

Data-contract inspector

Validate a small event file, classify every record, reconcile outcomes, and publish a plain-English report without hiding malformed evidence.

System boundary

One immutable synthetic event file and one versioned contract enter a local command. The command never edits its input; it emits accepted records, a restricted quarantine reference, and a report whose exclusive outcome counts equal the source total.

Milestones

  1. Declare row grain, stable event ID, types, ranges, clocks, and schema version.
  2. Parse without coercing unknown or malformed values into plausible records.
  3. Classify accepted, duplicate-equivalent, duplicate-conflicting, quarantined, and rejected records.
  4. Publish a deterministic summary and verify it from a clean directory.

Acceptance checks

  • Every source record has exactly one stable outcome and reason code.
  • Outcome counts sum to source count and accepted IDs are unique.
  • Repeated runs over identical bytes produce equivalent reports.
  • Future time, wrong unit, missing field, and conflicting duplicate fixtures are detected.
  • Diagnostics exclude private payloads and failed publication preserves the last report.

Extend it

Add a compatible contract version, a breaking version, and a migration report that explains which consumers must change.

12 · APPLIED · INFRASTRUCTURE

Local request-path observatory

Run one supervised HTTP service and trace a request through process, file, listener, route, socket, protocol, resource, and user evidence.

System boundary

A disposable local environment owns one static or tiny Python service, explicit configuration, a loopback listener, bounded client, and sanitized observation notebook. It never changes host routing or security policy and cleans every child, socket, and temporary file.

Milestones

  1. Record artifact, process identity, working directory, descriptors, limits, and graceful lifecycle.
  2. Map loopback address, route lookup, listener, connection tuple, HTTP request, and response.
  3. Measure concurrency, descriptors, latency distribution, failures, and cleanup under bounded load.
  4. Seed and diagnose wrong path, occupied port, partial request, timeout, and low file limit.

Acceptance checks

  • One command starts, verifies, and always cleans the exact recorded process.
  • The notebook separates observed evidence, inference, policy, and unknowns.
  • Each failure is located before an unrelated configuration change is attempted.
  • Client deadlines, frame and body limits, concurrency, and descriptor use remain bounded.
  • A second learner reproduces two failures and restores the ordinary request independently.

Extend it

Add a local TLS proxy with a test certificate, then distinguish DNS, TCP, TLS, HTTP, and application failures in the notebook.

13 · ADVANCED · AI SECURITY

Tenant-safe RAG release gate

Prove that corpus, retrieval, context, citations, cache, and preview never cross tenant authority before promoting a RAG release.

System boundary

Three synthetic tenants share one versioned corpus and evaluation harness. Authenticated test identity determines scope before lexical or vector candidates; generated output, citation preview, caches, logs, and evaluator artifacts remain inside the same authority and retention contract.

Milestones

  1. Create public, shared, private, stale, poisoned, conflicting, and deleted document fixtures.
  2. Assert authorization at lexical, vector, fusion, rerank, context, answer, citation, preview, and cache stages.
  3. Measure retrieval recall, claim support, refusal, latency, cost, and hard leak invariants separately.
  4. Run candidate-versus-baseline release comparison, canary probes, rollback, and clean handoff.

Acceptance checks

  • No forbidden source identity reaches any downstream stage or diagnostic artifact.
  • A highly relevant cross-tenant passage cannot win through semantic ranking or cache reuse.
  • Unsupported, conflicting, stale, and access-denied cases abstain with safe reasons.
  • Every run binds corpus, parser, chunks, indexes, prompt, model, validator, policy, and judge versions.
  • A security regression blocks promotion regardless of average answer-quality improvement.

Extend it

Simulate a production adapter that ignores one filter parameter and prove the gate detects the real candidate leak before generation.