How we built sportspage.io as a child theme of Peerless: ten custom modules, everything else inherited, and one repo deploying two production sites.
Most theme demos live on a staging URL nobody visits. We wanted a harder test for Peerless: a real production site with its own brand, its own audience, and plenty of reasons to diverge from the base theme. That site is sportspage.io, a portfolio platform built for athletes.

The brief
Sports Page needed things a business theme does not ship with: athlete stat blocks, recruitment-focused profile layouts, and a visual identity that looks nothing like a software company site. The question was whether Peerless could power it without being forked into a second codebase we would have to maintain forever.
A child theme, not a fork
HubSpot themes support inheritance, so Sportfolio (the theme behind sportspage.io) declares a single line in its theme.json: "extends": "src", pointing at Peerless. Every module, template, layout, and stylesheet in the base theme is available immediately. A fork would have meant fixing every bug twice; a child theme means the base keeps improving underneath the site that extends it.
Ten modules where it mattered

Peerless ships with more than forty modules. Sportfolio adds just ten of its own: two stat-block variants, a testimonial layout, a social connect block, a header variant, and a page-turn animation toggle among them. Navigation, footer, forms, the blog, CTAs, pricing tables: all inherited, zero lines rewritten. The home and landing page templates are the only structural overrides.
Rebranding was a variable swap

The two sites share almost all of their CSS and look nothing alike. Peerless keeps its design tokens in CSS variables at :root, so the child theme restyles by reassigning tokens rather than overriding rules selector by selector. The ITCSS layering keeps those overrides shallow and predictable. It is the same mechanism we describe in Theming with CSS Variables, exercised on a real brand instead of a hypothetical.
One repo, two production sites
There is no build step. Both themes live in one repository, and pushing a branch triggers a deploy of both to the matching HubSpot environment: sandbox, staging, or production. Fix something in the base theme and fcpsolution.com and sportspage.io both pick it up on the next push. The marginal cost of the second production site was ten modules and a stylesheet.
The takeaway for agencies
This is the workflow we would hand any team running multiple client sites on HubSpot: one disciplined base theme, thin child themes per brand, and spacing owned by sections so pages stay predictable, a principle we covered in Why Peerless Modules Ship with Zero Margins. Build the hard parts once; let every site after that be mostly configuration.
About the Author
Founder, Developer, Marketer of Sports Page.
Comments
July 8, 2026
From Drupal to HubSpot: Rebuilding paloaltou.edu with Peerless Components
July 8, 2026
Powering a Sports Portfolio: BuildingSportsPage on Peerless
How we built sportspage.io as a child theme of Peerless: ten custom modules, everything else inherited, and one repo…
July 7, 2026
Turn One Blog Post Into a Week of Social Content
You do not need a new idea every day. One solid blog post breaks down into five or six days of social posts if you know…
July 7, 2026
Why Your HubSpot Blog Needs Tag-Based Categories, Not Just One Feed
One long feed of every post you have ever written is not a content strategy. Tags, used as categories, turn a blog into…
July 7, 2026
Blog Feed v2: Tag-Filtered Feeds and Faster Cards
The blog-feed module was rebuilt from the ground up: recent posts, tag-filtered feeds, tag tabs, and a card layout you…
July 7, 2026
A New Pricing Table Module, Built for Side-by-Side Comparison
The rebuilt pricing-table module lays out multiple tiers, feature sections, and checkmarks side by side, driven…
