demi

demi

A demi-glace starts concentrated. Nothing extra goes in just because the kitchen has it nearby. You do the same with code: build the smallest useful version that satisfies the ticket, fits the repo, and can be verified. Complexity has to earn its way into the pan.

Core principle: start simple enough that reduce should not be needed immediately afterward. Small means understandable and verifiable, not cramped. The shortest version that hides intent is not demi; it is just dense.

The demi ladder

Before writing custom code, stop at the first rung that holds:

1. Does this need to exist? If the current behavior already satisfies the actual ask, skip the change and say why.
2. Can the repo already do it? Use existing commands, helpers, components, config, conventions, and tests before inventing new ones.
3. Does the standard library cover it? Prefer built-in language or framework features over custom code.
4. Does the platform cover it? Native browser, database, shell, operating system, framework, or deployment features beat owned code when they fit.
5. Does an already-installed dependency cover it? Use what is already in the project. Do not add a dependency for a few clear lines.
6. Can one explicit local change do it? One function, one component, one endpoint, one flag, one small data path.
7. Only then: write the minimum custom implementation that works and can be checked.

The ladder is quick. Do not turn it into a research project. If two rungs work, take the higher one unless it is less correct on edge cases.

The demi pass

Run this before editing:

1. Restate the actual ask. One sentence. If the task is vague, choose the smallest useful interpretation that still satisfies it.
2. Find the local pattern. Read the nearest existing code, helpers, tests, and naming conventions. Prefer what the repo already uses.
3. Climb the ladder. Check existing behavior, repo primitives, standard library, platform, installed dependencies, and local one-change solutions before new infrastructure.
4. Name the smallest useful slice. Define the first complete behavior the user can actually run, click, test, or review.
5. Cut speculative scope. Remove features, settings, abstractions, options, data models, and UI states that are not required for that slice.
6. Pick the boring implementation. Use direct code, existing helpers, and local composition. New abstractions need evidence.
7. Set a growth trigger. Write down what future fact would justify expanding the design: a second consumer, a third repeated pattern, a measured performance limit, a public API boundary, or an explicit user requirement.
8. Verify the slice. Run the narrowest meaningful check through check. If behavior is hard to pin down, use taste for a focused test before expanding.