Rebuild from failure

You are a senior product engineer. Turn the product idea below into a locally runnable MVP.

## Idea

Rebuild from failure
Uses one concrete system failure to make users rebuild key parts of Git, Redis, or a database from scratch.

## Product concept

A programmer who wants to write Git from scratch over the weekend opens the page and chooses “I only have two hours” instead of facing a long course. The system provides a small, runnable repository with missing parts and introduces one concrete incident: two objects have identical content but different hashes, or an index is corrupted after a power loss. The user can fix the incident only by implementing one missing component and running terminal commands. Afterward, the system shows which real mechanism in Git, Redis, or a database it represents. The next level automatically removes more scaffolding based on the user’s recent error, gradually returning control to the user. Unlike following a tutorial to reproduce a complete project, the core experience is to encounter a system failure first, then be forced to rebuild the layer that restores it.

## Why now (backed by facts)

As of the signal-observation date of July 12, 2026, Ship That Code’s “Build Redis, Git, and a Database from Scratch” Show HN post had about 133 points and 37 comments. At the same time, Ship That Code had launched more than 80 build-oriented courses, while CodeCrafters announced on May 22, 2026 that it was pausing development of new challenges. This suggests that demand for building systems from scratch remains active, while there is a current opening for a differentiated experience built around short sessions, incidents, and dynamically removed scaffolding, as well as for additional practice content.

## Direction (model inference, not independently verified)

Target user: Developers with some programming experience who want to understand the internals of Git, Redis, or databases over a weekend but do not want to commit to a complete course lasting dozens of hours. They open it for a one- to two-hour practice session or while preparing for a systems-focused interview.

Minimal entry point: Build one Git incident that can be completed in under two hours: provide a runnable repository with missing object-write or index-recovery logic, let users locate the problem through the terminal and complete the implementation, and use automated tests to determine when the repair is complete.

The strongest case against: The strongest case against this is that each high-quality incident must be realistic, reproducible, automatically gradable, and appropriately difficult. The production and maintenance cost of a single exercise may be too high to expand the library sustainably.

These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty.

## Punching above weight (model inference)

Turn each independently playable incident page into a public search entry point for a specific failure, such as “Git identical content produces different hashes” or “Redis AOF recovery after power loss.” Then publish free, runnable incidents on Hacker News, relevant technical communities, and among build-your-own-X audiences.

## Competitors & gaps (model inference)

- CodeCrafters: CodeCrafters has users build complete systems such as Git, Redis, and SQLite from scratch in stages. This idea narrows the entry point to one time-limited incident, with the focus on diagnosing the failure first and then rebuilding the missing mechanism that caused it.
- Ship That Code: Ship That Code offers many from-scratch courses for Git, Redis, databases, and other systems, with a public flow of choosing, coding, and running each lesson. The gap here is to start with a damaged repository and a concrete incident, then remove scaffolding dynamically based on the user’s previous error.
- SadServers: SadServers has validated the hands-on format of giving users a broken real environment to repair, but it mainly covers Linux, DevOps, and infrastructure troubleshooting. This idea takes incident training further into code reconstruction around Git objects, Redis persistence, and database indexes.

## How it makes money (model inference)

Charge per incident pack or through a monthly membership; offer a small set of free introductory Git and Redis incidents, with the full library, advanced failures, and learning records behind the paywall.

## Signal background

Theme: Learning programming by rebuilding Redis, Git, and databases from scratch
Trigger Hacker News post (original English): Show HN: Learn by rebuilding Redis, Git, a database from scratch
Heat at capture: ~133 points, 37 comments (point-in-time values)

The signal data is a historical snapshot from the moment it was captured; heat values drift over time and only explain “why now.” Do not write them into product copy as precise market numbers.

## Sources

- Ship That Code — Build Real Systems, Not Tutorials (https://shipthatcode.com/)
- We're pausing new challenges (https://codecrafters.io/blog/pausing-new-challenges)
- How Challenges Work (https://app.codecrafters.io/concepts/overview)
- Make Money Creating SadServers Scenarios (https://docs.sadservers.com/docs/make-money-creating-scenarios/)

## Deliverables

- Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery.
- Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary.
- Do not show unverified market numbers in the UI or API.
- Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge.
- If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code.
- If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype.
- When done, explain what changed, how to run it, and how to verify it.
- Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.

Uses one concrete system failure to make users rebuild key parts of Git, Redis, or a database from scratch.

Published July 12, 2026 · Editor GPT‑5.6 Terra · Ideation/facts GPT‑5.6 Sol · 4 sources

A programmer who wants to write Git from scratch over the weekend opens the page and chooses “I only have two hours” instead of facing a long course. The system provides a small, runnable repository with missing parts and introduces one concrete incident: two objects have identical content but different hashes, or an index is corrupted after a power loss. The user can fix the incident only by implementing one missing component and running terminal commands. Afterward, the system shows which real mechanism in Git, Redis, or a database it represents. The next level automatically removes more scaffolding based on the user’s recent error, gradually returning control to the user. Unlike following a tutorial to reproduce a complete project, the core experience is to encounter a system failure first, then be forced to rebuild the layer that restores it.

Why now

As of the signal-observation date of July 12, 2026, Ship That Code’s “Build Redis, Git, and a Database from Scratch” Show HN post had about 133 points and 37 comments. At the same time, Ship That Code had launched more than 80 build-oriented courses, while CodeCrafters announced on May 22, 2026 that it was pausing development of new challenges. ^S1^S2 This suggests that demand for building systems from scratch remains active, while there is a current opening for a differentiated experience built around short sessions, incidents, and dynamically removed scaffolding, as well as for additional practice content.

Target user

Developers with some programming experience who want to understand the internals of Git, Redis, or databases over a weekend but do not want to commit to a complete course lasting dozens of hours. They open it for a one- to two-hour practice session or while preparing for a systems-focused interview.

Minimal entry point

Build one Git incident that can be completed in under two hours: provide a runnable repository with missing object-write or index-recovery logic, let users locate the problem through the terminal and complete the implementation, and use automated tests to determine when the repair is complete.

Punching above its weight

Turn each independently playable incident page into a public search entry point for a specific failure, such as “Git identical content produces different hashes” or “Redis AOF recovery after power loss.” Then publish free, runnable incidents on Hacker News, relevant technical communities, and among build-your-own-X audiences.

Competitors & gaps

CodeCrafters: CodeCrafters has users build complete systems such as Git, Redis, and SQLite from scratch in stages. This idea narrows the entry point to one time-limited incident, with the focus on diagnosing the failure first and then rebuilding the missing mechanism that caused it.
Ship That Code: Ship That Code offers many from-scratch courses for Git, Redis, databases, and other systems, with a public flow of choosing, coding, and running each lesson. The gap here is to start with a damaged repository and a concrete incident, then remove scaffolding dynamically based on the user’s previous error.
SadServers: SadServers has validated the hands-on format of giving users a broken real environment to repair, but it mainly covers Linux, DevOps, and infrastructure troubleshooting. This idea takes incident training further into code reconstruction around Git objects, Redis persistence, and database indexes.

How it makes money

Charge per incident pack or through a monthly membership; offer a small set of free introductory Git and Redis incidents, with the full library, advanced failures, and learning records behind the paywall.

The case against

The strongest case against this is that each high-quality incident must be realistic, reproducible, automatically gradable, and appropriately difficult. The production and maintenance cost of a single exercise may be too high to expand the library sustainably.