When is it worth building a component vs designing the screen directly?

When you are in the middle of designing a screen and meet an element that looks repeatable, it is worth building the component only once the real pattern has emerged and stabilized, and worth designing the screen directly while the pattern is still forming. The deciding factor is timing: is abstracting right now premature? Design-first-then-extract beats abstracting on a guess, because you cannot build a good general component out of a pattern you have only seen once and do not yet fully understand. The right moment to abstract is after the pattern has proven its shape, not before.

The reasoning is about what you know at each stage of the work. Early in designing a screen, a repeatable-looking element is still a hypothesis. You do not yet know which parts of it are essential, which will vary across uses, or whether the version in front of you is even the right one. If you stop to build a polished, configurable component at that point, you are encoding guesses into an abstraction, and worse, you slow down the exploration that would have told you what the pattern actually is. The habit of building a component for everything before the screen is even resolved feels productive, but it abstracts prematurely and stalls the very exploration that reveals the real shape. You end up maintaining a general thing built around a specific guess.

A concrete sequence shows the timing in action. Say you are designing a dashboard and you place a small metric tile: a label, a number, a trend indicator. It looks like it might repeat. The premature move is to immediately build a flexible MetricTile component with props for every conceivable variation before you have laid out the rest of the screen. The better move is to design the next few tiles directly, by hand, as part of working out the screen. Doing that, you discover that some tiles need a comparison line, one needs no trend at all, and two share a layout you did not anticipate. Now the real pattern has emerged. You extract the component from three real, stabilized instances, and it fits all of them because it was shaped by them rather than by your initial guess.

There is one place this bends: not every element should wait, and waiting too long has its own cost. When a pattern is already well understood from prior work, a standard form field or a button you have built a hundred times, there is no exploration left to do and no reason to design it from scratch on each screen. Reach for the component immediately, because the pattern stabilized long ago. The judgment is honest: an element is ready to abstract when its shape has stopped changing, whether that happened on this screen after three uses or in a previous project years ago. The mistake on the other side is hand-building, screen after screen, something that clearly settled long ago and should have been a component already.

It is worth being clear about what this question is and is not. It is not whether the pattern is reusable at all, which is a separate decision about real or likely repetition. This is about timing during active screen work: assuming the pattern is reusable, when do you stop designing directly and extract it? The answer is when it has stabilized, and the way you find out it has stabilized is usually by designing the screen directly until the pattern reveals itself across a few honest uses.

So decide by whether the pattern has stopped moving. While a pattern is still forming, design the screen directly and let the work teach you its real shape, then extract the component once two or three concrete instances agree on what it is. Skip the wait only when the pattern is already understood from past work and has nothing left to reveal. Before you stop to build a component mid-screen, ask whether you have actually seen the pattern settle or are only guessing at it. If it is a guess, keep designing, and extract when it proves itself.