One Codebase, Two Brands
First published on the Barnes Foundation's Medium, May 2026.
Creating Calder Gardens: How the Barnes operates digital systems across partner institutions
The previous installment in this series followed the origin and evolution of the Barnes Foundation’s Visual Experience Platform (VXP), a teaching environment designed and built in house to support sustained engagement with works of art in a digital space.
What follows is a story taking place on the visitor-facing side of the operation (and right across the street on the Ben Franklin Parkway here in Philadelphia): how the Barnes built and maintains the ticketing, membership, and web infrastructure that serves both itself and Calder Gardens, and what it means to run a shared digital operation while preserving each institution’s individual brand.
The Operating Partnership
Calder Gardens, a new institution dedicated to Alexander Calder, opened in September 2025. The building is by Herzog & de Meuron, the gardens are by Piet Oudolf, and the rotating installation of Calder works inside is built around a deliberate rhythm of repeat visitation with rotating works. Programming spills past the galleries into performances, meditations, sonic experiences, screenings, and lectures.
The Barnes Foundation is the operating partner of Calder Gardens, but Calder Gardens, as a brand, is its own distinct identity, and that distinction shaped everything that led up to opening day. The digital systems described here are designed for structural unity at the infrastructure layer and brand independence at the public-facing layer. For us on the web development team, the question was: could systems built to serve the Barnes also serve a second brand without doubling our engineering effort, and without compromising the experience for our audience?
One Codebase
The Barnes and Calder Gardens visitor-facing web properties all share a single GitHub “monorepo”. Every consumer-facing surface across both brands lives in that single repository: the membership portal, the public ticketing flow, the membership purchase flow, the SMS ticket fulfillment site, the on-site kiosk checkout, the donate site. Each of them ships in two versions, one Barnes and one Calder Gardens, but the versions are not so much separate products as different deployments of the same product.
Brand switching is environment-driven so a single workspace builds once and renders as either brand depending on a variable set on deployment. The member portal, for instance, ships two production deployments from the same code, one to members.barnesfoundation.org and another to members.caldergardens.org. Configuration constants like admission IDs are duplicated per brand in environment files and the code reads whichever brand applies to the current deploy and proceeds accordingly.
The visual identity layer is Mantine UI, set up with a deliberate inheritance pattern. A shared base theme defines what is consistent across brands. On top of that, two brand themes layer their own tokens using Mantine’s theming API. Brand-specific fonts, heading scales, colors, and component overrides live in the brand theme. Anything shared across brands lives in the base and we created our own dual-branded component library built on top of Mantine allowing us to iterate quickly and deliver 14(!) sites ahead of opening.
This monorepo setup makes the dual-brand model operationally sustainable. A bug fix or an accessibility improvement made to a shared component is made in one spot and both institutions benefit. A brand-specific styling change touches only the brand theme. The shared component library lives in the common workspace and is consumed by every other workspace in the monorepo.
One ACME Tenant
Both institutions run on a single ACME ticketing tenant. The same API instance, the same customer records, the same backend and backoffice processes every transaction across both brands.
The integration between our code and ACME runs through a Node.js client library we built and published as open source (check it out here: BarnesFoundation/acme-ticketing-client). It standardizes requests to the ACME API, exposing primitives, events, ticketing, ecommerce, and memberships, baking in the required client/tenant identifiers and security tokens. Branding for our use case happens upstream, in calling services by way of configuration constants that map brand-specific ACME event and template IDs to the appropriate cart logic. A single and separate backend server workspace uses this client to run every public-facing transaction.
Brand differentiation, then, lives in three configuration layers rather than in code forks determining which ACME event or template ID gets used, which brand theme renders the purchase flow, which domain the user is on etc. The transaction pipeline itself (think error handling, payment, confirmation, and fulfillment) are all shared.
Our model for “Plus” admission, a single-purchase ticket type that admits a visitor to both the Barnes and Calder Gardens, is a perfect example of how this shared infrastructure is beneficial. We collaborated closely with our Business Systems team to iron out the logic. Now, when a visitor selects this ticket type, the server composes two ACME checkout lines, one Barnes admission and one Calder Gardens admission, into a single cart, and applies a cross-admission discount that exists in ACME as its own line item. The user adds one item to their order, the system fulfills two admissions and the discount is automatic, all enabled by a shared ACME tenant.
One Membership Program
The membership program is structured along the same lines. There is one Barnes Foundation membership, with a unified level hierarchy, and the same membership grants member hours, ticketing benefits, and event access at both Barnes and Calder Gardens.
What varies is the doorway. A member may arrive at members.barnesfoundation.org or members.caldergardens.org; the portal recognizes them as the same person, looks up the same membership record in ACME, and routes log-in links and cross-site navigation back to the brand domain they came from. This also helps with attributing where a membership originated from, Barnes vs Calder Gardens, for reporting purposes. Backend session management, ACME transaction handling, and fulfillment logic are shared across both portals. The brand-themed experience is presentation, and presentation only.
One Customer Database
The same operating principle extends past the codebase. The Barnes Foundation runs a single Salesforce CRM instance that holds member, donor, and visitor records across both brands. Someone who joins through Calder Gardens occupies the same database as someone who joins through the Barnes. Households, giving histories, engagement records, attributions by institution are consolidated across two systems.
Designed to Scale
This is what the dual-brand model unlocks at the operations and brand layers. Calder Gardens has its own visual identity, its own programming voice, its own marketing positioning, and its own way of inviting people in. But once someone becomes a member, a donor, or a repeat visitor, they enter a single customer-data layer that the Barnes operates. Essentially there are two front doors, one back office.
Although the system as built today serves two institutions, nothing about it is structurally limited to two. Every layer described above functions as a white-label platform: the monorepo with environment-driven brand switching, the Mantine base-and-brand theme inheritance, the brand-agnostic ACME client, the configuration-driven cart logic, and the shared component library. The architecture was built for reusability, maintainability, and easy brand switching, which means adding a third institution does not require a new codebase. It requires a new brand theme, a new set of environment variables, a new domain, and a new set of ACME event and template IDs.
The 14 sites we launched in 2025 are evidence of the model at work. Each was assembled from the same shared foundation with brand-specific configuration layered on top. The shared UI vocabulary and component library scales across future microsites and institutional products, and the marginal effort of each new surface declines as the platform absorbs more of the work. We intentionally designed the system for scale from the start!
What This Means for Our Audience
Because all of the dual-brand surfaces are powered by one shared codebase, every feature we build for one institution ships to the other at the same time. For example, when we launched digital membership cards, members arriving from either member site could add their card to their phone with a single tap, in one release. Every subsequent improvement to the add-to-wallet experience has benefited members across both brands without a separate engineering track.
The Plus admission ticket type, the single-purchase ticket that admits a visitor to both the Barnes and Calder Gardens, exists because we built ticketing to compose admissions across institutions rather than treat them as separate purchase paths. A visitor who wants to visit both locations in a single day buys one ticket. On site, mobile tickets surface upsell paths just a few taps away, suggesting the value of visiting the other location across the street, at a discount.
The list extends through every release: membership upsells, post-purchase join prompts, accessibility improvements, session and recovery patterns that behave the same on a Barnes ticket purchase as on a Calder Gardens event registration, content tailored so that members see the benefits relevant to them. Each improvement is implemented once and serves both audiences.
The Barnes Foundation exists to promote the advancement of education and the appreciation of the fine arts. Calder Gardens extends that mission into a new physical and curatorial context. The visitors, members, students, and supporters who engage with either institution deserve a digital experience that is reliable, accessible, and built around their actual needs. The dual-brand architecture makes that easier to deliver because the work compounds.
What’s Next
The final post in this series steps back from individual systems to describe the ways of working that hold them together: the platform versus project distinction that informs how we scope work, and the emerging role of AI-assisted development practice in maintaining coherence across a growing portfolio of digital products.
Follow the Barnes Foundation on Medium for the rest of the series. This is the third post in a series on digital work at the Barnes. If you missed the first, start here.
One Codebase, Two Brands was originally published in Barnes Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.