Examples Are Part of the Product In short: The moment a developer opens your source to work out how to use a component, the library has failed as a product. Executable examples fix that — and they become your visual regression baseline for free. Static documentation decays. Three months of active development after you wrote the README, it says an input is optional that is now required, and it shows an example that no longer compiles. Developers find this out once. After that they stop reading the docs, ask in Slack, and — when Slack is slow — copy the component into their own feature. That is the trust failure from lesson one, arriving through documentation instead of through a breaking change. The fix is documentation that cannot go stale, because it is code that runs. The living specification A sandbox renders components in isolation, away from routing, HTTP, and application state. Storybook is the common choice for Angular. This forces something useful on you. A component that cannot render in a sandbox is a component that is secretly coupled to application infrastructure — it injects a , or a store, or reaches for a global. The sandbox surfaces that on day one rather than in Chapter 7 when a second application tries to use it. Here is the from lesson four, documented: The line matters: the API table is generated from your TypeScript, so it cannot drift from the code. Rename an input and the docs rename with it. Note the last three stories. , , and are the ones that catch real bugs — a stepper with one step should not draw a connector, and a stepper with a 60-character label should not overflow its container. Writing them is how you find out. Which stories to write A story per input combination is impossible, as Chapter 3 established. A story per meaningful state is achievable: Story Catches --- --- Default The normal case Each state of the primary union A missing branch Empty collection The empty-state gap Single item Off-by-one layout (connectors, dividers, separators) Long text Overflow, truncation, wrapping Disabled / read-only Contrast failures on disabled elements Narrow container Responsiveness, which Chapter 6 covers with container queries That is seven or eight stories for a typical component, and it is a genuinely good coverage set. Stories are test fixtures This is the part that changes the economics. Every story you write for documentation is a rendered, isolated, deterministic component state — which is exactly what a visual regression test needs. Chapter 8 points Playwright at your Storybook build and screenshots every story. You do not write a separate set of visual test cases; the documentation is the test suite. The same applies to accessibility. runs against the story you are looking at, live, while you build the component. You find a contrast failure at authoring time rather than in a CI report a week later. So a story earns its keep three times: 1. It documents the component. 2. It is a visual regression baseline. 3. It is an accessibility check. That is why "we do not have time for Storybook" usually turns out to be false — the time is being spent, just later and in worse ways. The README still matters Stories show how a component looks in each state . They are bad at explaining when to use it and why it exists . Keep a short README per library: Short, and none of it is the kind of thing that goes stale in three months. "But I thought Storybook was overhead we could skip for an internal library" This is a reasonable call to make under deadline pressure, and it is usually justified with: everyone here can just read the source. For a three-person team sharing four components, that is true. It stops being true at a point most teams pass without noticing, and the failure is not "people are mildly inconvenienced". It is more specific than that. Reading the source does not tell you what it looks like. A developer can read in full and still not know whether a five-step stepper wraps on a narrow screen. To find out, they have to wire it into their app with realistic data. That is fifteen minutes per component, per developer, repeated forever — and it is why the copy-paste habit starts. Once someone has done that work, pasting the result into their feature is faster than doing it again. Nobody discovers what already exists. Ask a team of twenty whether the library has an empty-state component and you will get four answers. Without a browsable catalogue, a component that exists but is not known is functionally a component that does not exist, so it gets built again — differently. The edge cases never get rendered. This is the expensive one. Without stories, nobody ever looks at the stepper with zero steps, or with a very long label. Those states first appear in production, in front of a user, and get reported as "the dispatch page is broken". The comparison over a year, for a library of 25 components used by three applications: No sandbox Storybook --- --- --- Time to evaluate a component for…