How a Reusable Component System Built the St Andrews Links App

Every app needs the same basic pieces: sign-in, navigation, lists, cards, and a way to talk to servers. The question is whether you rebuild them every time or start from a foundation you have already tested, and spend your effort on what makes the app different. For the St Andrews Links Home of Golf app, we started from shared components. Here is how that worked.

Key takeaways

• Our component system combines reusable UI parts with shared code for networking, authentication, and common helpers.
• A central reference page for UI elements, often called a kitchen sink, kept visual and interaction changes in one place.
• When St Andrews Links updated its digital brand a few months into the project, the changes went into shared components instead of every screen.
• Components that prove useful on one project can move into the shared core for the next.

Why do components suit a heritage brand app?

In our view, a brand like St Andrews Links cannot afford an app that feels inconsistent. A component-first approach defines repeatable layouts and behavior up front, so every screen starts from the same parts. Design, engineering, and QA work from shared pieces instead of one-off screens. For how the design side was set up, see how we built the design system.

What is in our component system?

We reuse two kinds of building blocks:

• Shared code: things every app needs, such as network requests, connectivity errors, and date and distance helpers.
• Shared features and UI parts: authentication and session handling, plus design-library components such as loading views, segmented controls, and calendar selectors.

The system keeps changing. In an internal audit, our iOS team listed components from the St Andrews Links and Foxwoods apps and marked several of them, including a calendar selector and a multi-select control, to move into the shared core. You can read about the Foxwoods side in how we built its digital ecosystem.

What is a kitchen sink page, and why use one?

A kitchen sink page is one reference that shows every UI building block in one place: text inputs, dropdowns, fonts, and colors. On the Home of Golf app, we styled it to the St Andrews brand at the start of the project. That did two things. Each element was defined once and reused throughout the app, and there was one place to go if the branding ever needed to change.

What happens when a brand changes mid-project?

Brand updates happen. A few months into the project, St Andrews Links updated its digital brand, and the app needed new colors, fonts, and element styles. Because they were defined in shared components, we changed them in one place and the update carried through the app. In our account of the project, that kept a brand change from turning into a screen-by-screen rebuild. More of our finished work is in our work.

Does reuse make an app feel generic?

Not in our experience. Shared components govern structure and behavior. Brand expression still comes from colors, type, content, and product decisions. The time saved on common pieces can go to what is specific to the product, such as the digital course guides in the Home of Golf app.

What should teams take from this?

A component system pays off most when it keeps improving. Patterns that work on one project become better defaults for the next, adapted to each brand. Our services page explains how we work with hospitality and golf teams.

Planning an app for a heritage brand? Talk to us.