Feature Design

The work that happens before the first line: goal, rules, state changes, interfaces, persistence, errors, observability, tests — and what fails if you skip it.

Designing a Feature Before Writing It
▶ lab

Eight questions stand between a ticket and the first line of code. Skipping one does not remove the decision — it relocates it to whichever branch of the code happens to run first.

Q · A ticket says "let customers pause their subscription". What has to be decided before I open an editor, and in what order?
A Feature Design Template
▶ lab

Twelve fields, filled in for a real feature. The value is not the document — it is that a blank field is visible in a way an unasked question is not.

Q · How do I make the questions I skipped visible to a reviewer, without turning feature work into a documentation process?
Failure-Aware Feature Design

Four questions that change the structure rather than adding a branch: what if the database is gone, the dependency is slow, the request arrives twice, and half the work already succeeded.

Q · The happy path works. What does this feature do when the write fails, the dependency times out, the request repeats, or part of the work has already committed?
Designing the Happy Path Last

Error, repeat and partial-failure behaviour decided first, because a structure built around the success case has no room left for them — and that is where the mess comes from.

Q · Why does error handling always end up feeling bolted on, even on teams that genuinely care about it?
Slicing a Feature

A slice is a thin path through everything that delivers something observable. A layer is a horizontal band that delivers nothing, and calling it a slice is how all the risk ends up in the last week.

Q · How do I break a three-week feature into increments that are each safe to release and useful on their own?