Designs are often presented and approved page by page, and it is tempting to build them the same way. The result is a site where the same card or button has been coded five slightly different times. Each later change has to be made five times, and one of them is always missed.
Building from components reverses the order. The parts are built and checked first, and pages are put together from them, much like a printed publication assembled from a fixed set of styles.
Look for the repeats
Before writing code, go through every design and list the parts that appear more than once: buttons, form fields, cards, headings, navigation, testimonials, pricing tables. Usually a few dozen parts make up almost every page. Those are the real building blocks.
Give each part a plain name that designers and developers both use. “Product card” is better than a name only one side understands. Those names then carry through into the code and the design file.
Settle the variations
Many repeats are not quite identical. One card has an image and one does not; one button is primary, another secondary. Decide which differences are deliberate, turn them into a small set of variants, and treat the rest as inconsistencies to be removed with the designer.
This conversation often improves the design itself. Seeing all the variations side by side makes it obvious which ones earn their place, and which ones were accidents.
Build and check each part alone
Build each component on its own, with every variant and state, and look at it outside any page. It becomes clear quickly whether it handles long text, missing images or narrow screens. Pages assembled from checked parts have far fewer surprises.
Keep these checked parts in one place where the whole team can see them, with every variant laid out. It becomes the reference for new pages and the first stop when something looks wrong.
Share one source with design
The components in code and in the design file should match in name and behaviour. When the designer adds a new variant, the developer knows exactly where it goes. This shared vocabulary makes conversations shorter and later work much faster.
When a component changes, change it in both places at once. Letting the design file and the code drift apart slowly undoes the benefit.
