With reusable parts you extend your site: you build something once and place it anywhere, always identical.
Example: a reusable part
Create a reusable pricing-table component and put it on the pricing page.Custom work?
An integration with another system or a fully custom app is built for you by Ster Software — get in touch.
Why reusable components pay off
Reusable components save time the moment you need the same piece of UI in more than one place — a pricing table, a call-to-action, a team member card. Build it once and every future update lands everywhere it is used, instead of hunting through pages one by one.
A common use case: an FAQ block that appears on your homepage, your pricing page and a landing page. Update an answer once and it changes everywhere automatically — see the FAQ block for how that works in practice.
Components combine well with data types: a data type defines the content, a component defines how it is displayed, so you can reuse the same layout across completely different lists.
Practical tip: keep components focused on one job. A component that only renders a records list is easier to reuse and maintain than one that tries to handle five different layouts at once.
When a component makes sense — and when it doesn't
Not every repeated piece of content needs to become a component. If something appears once or twice and is unlikely to change, a plain block on the page is simpler and easier to reason about. The tipping point is usually three or more places: once you are copying the same structure a third time, a shared component starts paying for itself, because a single edit then reaches every instance instead of three separate ones that can quietly drift apart.
A frequent mistake is building a component too early, before it is clear what actually varies between its uses. Start with the plain, duplicated version on a couple of pages, notice which parts genuinely stay identical and which parts differ, and only then extract a component with props for the parts that change.
Components across different kinds of sites
A retailer with dozens of product pages benefits from a component that renders a consistent product card — image, price, a short description — wherever products are listed, whether that is a category page or a "you might also like" section. A membership organisation might instead reuse a component for a speaker or board-member profile across an about page, an event page and a newsletter archive. The pattern is the same even though the content is completely different: one definition, many places.
Sites that combine dynamic pages with components get the most leverage, since a single component can format every record in a list identically without any manual formatting per item.
Getting a custom integration right
When a component needs to talk to an external system — a booking calendar, a stock feed, a payment provider — that is no longer a simple layout component but a genuine integration, and it is worth being upfront about that distinction. Rushing a fragile integration together as a quick component tends to cause more support requests later than the time it saves now.
If you are unsure whether something should be a reusable component or a proper custom app, describe what you are trying to achieve to the assistant, or reach out directly — see how content is built as JSX for background on how components fit into a page, and check pages for how blocks and components come together on a single page. For components that need to loop over a list themselves rather than through the records block, the each block gives you the same repeating pattern with more control over the wrapper markup.