The engineering wall, and who is standing behind it
Every piece of documentation in Storybook is a file in a repository. That is its superpower - versioned, reviewed, deployed with the code - and its wall. The designer who knows why the destructive button is red cannot write that down without an engineer. The content designer who spots a wrong sentence files a ticket instead of fixing it. The wall does not show up in any feature list, but it decides who contributes: over time, Storybook docs contain exactly what engineers thought to write, and nothing else. That is usually excellent API documentation and almost nothing about when, why, or whether to use a component.
Where Storybook is unbeatable, and we will not pretend otherwise
For the code itself, nothing competes. Autodocs reads props, types and defaults from the source, so that documentation cannot drift - it is the component. The rendered examples are the real thing, interactive, in every state. The history is git, which means it is complete and permanent, which beats our 180 days without discussion. And it costs nothing. If your entire audience is developers and your system is young, Storybook alone is a perfectly good answer, and cheaper than we will ever be.
Most teams should run both, and here is the split
Storybook documents the component as built: API, states, behaviour - by engineers, for engineers. Pentrical documents the system as designed: guidelines, tokens, measurements from Figma, the reasoning - by the whole team, for the whole company. The overlap is smaller than it looks, and the pairing is common enough that we would call it the default: link from the guideline page to the story, and from the story back to the guideline. What we would not recommend is stretching either tool across the wall - MDX guidelines nobody updates, or component APIs retyped into a CMS. Both of those are how documentation dies.
The cost that never lands on an invoice
Storybook is free the way a puppy is free. The docs are code, so every improvement competes with feature work in the same sprint, reviewed by the same people. Teams that flourish with docs-as-code have decided documentation is engineering work and staffed it accordingly. Teams that have not made that decision get the other outcome: a beautiful component explorer, six MDX pages from 2024, and a design system that lives in someone's head. If that describes your Storybook, the problem is not Storybook - it is that half the job was never its job.
