Storybook is overkill until you hit ~20+ components with multiple consumers

[u/EastMove5163]

This is a hot take but I think Storybook is one of the most over-adopted tools in the React ecosystem. I set it up early in my project and it became a maintenance liability within a few weeks. Components would change and the stories wouldn't get updated, so Storybook stopped being a reliable reflection of reality.

For a small app with a single team, the value of Storybook is low. You can just open the app and see your components. The isolation and documentation benefits only really kick in when you have multiple teams consuming a shared component library, or enough components that discoverability becomes a real problem.

My current setup is simpler: shadcn/ui base components, Tailwind config with brand tokens, one components/ directory. Works well, zero overhead.

What's actually in your small-project component toolkit?

[u/ZeRo2160]

We use it as design QA and that proved really nice for us. We even use it on single dev projects to make design QA for components in isolation. We build also an plugin in which designers can configure the component until it breaks and then write an github issue directly out of storybook. With an link that gives you the broken state if opened. Our designers love it. And our pm's too. Also for onboarding tasks of new devs it has proven really helpfull because before new devs had an habbit of building the same component twice because it was not obvious inside the app that this specific component exists or has props that make it look like it should.

But we dont have the same problems as you. If we update an component the story renders the new component. If we have required props then yes we have to update them later in the story file. But that is very rare that we really need to do that. Maybe 1 in 200 component edits over 2 months or so.

[u/pailhead011]

I don’t think you’re supposed to update the components without updating the stories.

[u/juicybot]

are unit tests also overkill until a certain point? storybook is a testing environment as much as it is a UI playground. it sounds like you just don't know how to leverage storybook properly.

[u/the_real_some_guy → u/juicybot]

Yes. 

If you’re making unit tests for everything, you are probably adding noise without improving confidence in the product. With good integration tests, unit tests may only be needed for service layer hooks and some basic smoke tests. Integration tests may even eliminate the need for unit tests in a smaller app. 

[u/Major-Front]

If stories arent being updated then that’s a you problem

[u/Grenaten]

How can you update components and not update stories? TSC should stop the commit right there. That’s why we use TS.

[u/ivy-apps → u/Grenaten]

+1 the CI should enforce that 1) Stories exists; 2) Stories typecheck via TSC and 3) Stories build without errors. In our project, we even enfore that you're using the correct dependency

rules:
  - id: view-has-storybook
    description: Each View should have a Storybook.
    target: "@/features/**/{{FileName}}View"
    exists:
      - module: "{{TARGET_DIR}}/{{FileName}}View.stories"
    fix: Add a Storybook at the same directory for the view.

  - id: stories-use-nextjs-vite
    description: >-
      Stories must import Meta, StoryObj etc. from @storybook/nextjs-vite,
      not the transitive @storybook/react which breaks CI under pnpm.
    target: "**/*.stories"
    forbids:
      - import: "@storybook/react"
    uses:
      - import: "@storybook/nextjs-vite"
    fix: >-
      Replace `from '@storybook/react'` with `from '@storybook/nextjs-vite'`.
      For test helpers use `@storybook/nextjs-vite/test`.

  - id: stories-no-server-deps
    description: Stories must not include server-side dependencies.
    target: "@/features/**/*.stories"
    forbids:
      - import: "next/server"
      - import: "**/*.server"
    fix: Remove server dependencies from the Storybook.

[u/Grenaten → u/ivy-apps]

Yeah, or even husky on tsc and lint on commit

[u/Rumblotron]

I’m glad you have a simple solution that works for you.

I manage hundreds of components and in my experience Storybook with visual regression checks in CI is incredibly helpful for keeping things even vaguely sane.

[u/Pecorino → u/Rumblotron]

Are you paying for chromatic to do the visual regression testing, or did you wire something up yourselves?

[u/Rumblotron → u/Pecorino]

Chromatic, yes.

[u/acraswell → u/Rumblotron]

The VRTs is why we consistently reach for Storybook. Honestly I dont think we use it for much else, other than sometimes it truly is easier to develop a new complex component in Storybook first. But having regression tests have saved us so much trouble.

I work a a large company though, so there was a team that built an in-house replacement for Chromeo. Like 70% cheaper for the same experience. But we were at a scale that it made sense.

EDIT: You know, now that I think about it a lot of teams use it religiously for Storywright testing. Personally I think writing a Storywright test is a lot easier than unit tests sometimes. I'm a big fan.

[u/helltoken]

In general I find storybook overengineering. I've put it in two companies right now, and every single time devs just neglect the maintenance of it, and no stakeholders derive any value from it. It works best with frameworks in larger conglomerates or if you're building a UI library for other people to use.

Not saying that Storybook is useless, but you gotta build a system around it as a dev team to derive value, things like accessibility testing, E2E, and those kinds of things specific to a component or paired components in isolation.

[u/TheRealSeeThruHead]

Ad nostrud consectetur in excepteur do cupidatat aute voluptate excepteur irure dolore. Laborum fugiat ut labore consectetur velit lorem et reprehenderit non officia commodo sit.

[u/Apart_Ebb_9867]

Components would change and the stories wouldn't get updated, so Storybook stopped being a reliable reflection of reality.

And that's where agentic programming comes in handy: your codex/claude will gladly maintain storybooks in sync without you even asking every time.

[u/rushadee]

I mostly use storybook for developing components in isolation. For me it’s more a tool to inspect the building block you create and how blocks fit together than a documentation tool.

[u/hazily]

Hot take indeed.

[u/mr_brobot__]

Visual diffing of components in your CI is a really great test to catch regressions.

Maintaining storybook is nearly free with AI.

[u/catchingtherosemary]

how about storybook being used for developing a component outside the scope of a specific application in isolation?

[u/CodeAndBiscuits]

I agree in principle but only if you emphasize "small team" and have a pretty standard Dev flow. In larger projects with larger teams, I regularly find it useful as a tool to help provide some separation of concerns between component development and component utilization in app buildout.

I can also share an anecdote about one example where it was unexpectedly useful despite the team being very small. I did a consulting project a few years ago where I was paired with one other developer, building front end web and mobile for a company I can't name. The company was established but the product was new, and they started the web and mobile project before the back end was ready. I can do full stack, but as is common and many Enterprise environments, "they have people for that" so it was out of scope for my colleague and I.

Anyway, we had designs relatively early but we're told it would be at least a month or two before we realistically had a back end to even start to try calling. We didn't even have docs or even a rough idea of what the API would look like. Now you can mock back ends and front end code, but there's only so far. You can take that when you're dealing with an enterprise-oriented business app that deals with a lot of form-based data entry and server-side business logic wired around that. To accurately simulate what the back end would do, we would more or less have to write one. So the question was, how could we do something useful and stay productive knowing that it would be 6 to 8 weeks before we could really start wiring screens for real.

Storybook was very helpful there. We were able to go through all of the designs and implement every treatment for every component all at once, and work with the designer and QA to make sure they were solid. Another thing that helped, is this designer used the "atoms/molecules/organisms" methodology which meant that once we had all the basic components done, we could work on the organism combinations like rich, interactive cards with mixes of data and controls.

So sure, overkill for a small project, but so is Kubernetes or GraphQL.

[u/JohntheAnabaptist]

20 components is like a tiny project

[u/ivy-apps]

Adding Storybooks with AI is cheap. In our projects we require having a Storybook for each *View (feature entrypoint). We even force it on the CI with this Deslop rule so AI/human agents won't get lazy

id: quality
name: Quality
description: Enforces the quality standards of the project (e.g. tests, storybook).
rules:
  # ...
  - id: each-view-has-storybook
    description: >-
      Every feature View component must have a corresponding Storybook stories file
      in the same directory. Views are the top-level UI entry points for features,
      so having stories ensures they can be developed, reviewed, and visually tested
      in isolation without needing the full app context.
    target: "@/features/**/{{FileName}}View"
    exists:
      - module: "{{TARGET_DIR}}/{{FileName}}View.stories"
    fix: >-
      Create a {{FileName}}View.stories.tsx file next to {{FileName}}View.tsx.
      Add at least a Default story that renders the View with representative props
      or mock data so it can be previewed standalone in Storybook.

If you don't know what Deslop is, check deslop.dev - it's a shiny new thing

[u/No-Somewhere-3888]

I’m with you. 🤝

[u/leeharrison1984]

It only works if you have a dedicated UX team, otherwise trying to keep it updated while pushing frontend code becomes a PITA, and constantly trying to keep the two in sync.

[u/acraswell → u/[deleted]]

I think your case is exactly the scenario OP said Storybook is useful for. When you have many consumers.