The boilerplate that explains your product, not just itself

A starter kit's documentation has a short shelf life. It's accurate on day one, useful for about a week, and then you've renamed half the tables, added three features the docs never mention, and the AI assistant reading that context is confidently wrong about a codebase that no longer exists.

Most boilerplates accept this as the cost of moving fast. Keel doesn't, because the actual problem isn't the documentation going stale, it's that nobody's writing the new documentation as they go.

A folder, not a file

Keel ships memory/ instead of a single context file: MEMORY.md as the index, architecture.md for the why behind the non-obvious calls Keel itself made, conventions.md for naming and folder patterns, and decisions.md, which starts nearly empty on purpose. That last one is yours.

The habit, not the feature

The folder structure isn't the point, the habit is. When you make a real call, a new table, a billing rule, an auth tweak, you add a few lines to decisions.md:

## 2026-07-01, Projects are team-scoped, soft-deleted
Added a projects table scoped by team_id (same pattern as the
rest of the schema). Soft delete via deleted_at so we can offer
a 30-day restore window. Hard-delete job runs nightly.

Thirty seconds, and the next person, human or AI, who asks "why is this soft-deleted" gets a real answer instead of a guess reconstructed from the code.

Why this is the part that compounds

Every other piece of Keel, auth, billing, teams, is infrastructure you'd eventually build yourself. The memory/ system is the one piece that gets more valuable the longer you use it, because it's the only part of the codebase whose entire job is staying true to whatever you're building next.