Founder's in-house buildFounder's in-house work, not a client engagement - Rails 8 + Hotwire2026
Loyal
Built in-house as a Loyal employee, not as a Carlsbad Web & AI client engagement. A CTV and mobile publishing platform's full marketing site: two product pillars kept separate, a reach calculator a media buyer can push on, and a detail page for every app in the catalogue.
This build is the founder’s in-house work as a Loyal employee — not a Carlsbad Web & AI client engagement. It is shown because the craft is real and the site is live; it is labelled because the difference matters.
Our exact role
Founder's in-house work as an employee of Loyal, not a Carlsbad Web & AI client engagement. Designed and built the loyal.app marketing site — the design system, every page template, and the 200+ app catalogue.
The context
Loyal is a CTV and mobile publishing company with two businesses to explain: Loyal Publishing, its owned apps and CTV channels, and Loyal Exchange, its ad marketplace for publishers and demand partners. Carlsbad Web & AI's founder works at Loyal and designed and built the marketing site there. The site is his work. Loyal's business results are not ours to claim.
Where it started
The first version shipped as a static Astro build. It looked right, but the app catalogue, the exchange section, and the contact flow all wanted server-rendered data and an admin surface — things a static generator can only reach by bolting on a second system.
The constraint
Two audiences with opposite questions have to share one site. Publishers want distribution and revenue mechanics; advertisers want reach and targeting. Neither should have to read the other's pitch to find their own, and both want numbers they can push on rather than a claim to take on faith.
Decisions made
- 01Split the story into two pillars, Publishing and Exchange, so each audience gets its own path off the homepage instead of one blended pitch.
- 02Rebuilt on Rails 8 with Hotwire so the app catalogue and the admin surface render from real data, with no client-side framework in front of them.
- 03Kept interactivity on the Hotwire ladder — Turbo Drive for navigation, small Stimulus controllers only where a page genuinely needs behavior.
- 04Self-hosted the hero MP4 with a poster frame instead of embedding a third-party player, so the first paint never waits on someone else's script.
- 05Built the exchange pitch around a budget slider and a live reach estimate, so a media buyer tests the claim in the page rather than reading it.
What we built
- A design system — type scale, color, spacing, components — carried across every page template.
- Two product pillars: /publishing, and an /exchange section covering advertisers, publishers, StreamConvert, data, and partners.
- A 200+ title app catalogue with a detail page per app.
- A reach calculator driven by a monthly-budget slider running from $1,000 to $250,000.
- An autoplaying muted hero video with a poster fallback, plus scroll reveal, count-up, and nav-elevation behavior.
- Company, news, contact, and privacy pages, and an admin surface behind authentication.
More of the build
Stack
- Ruby on Rails 8
- Hotwire / Turbo Drive
- Stimulus
- importmap-rails
- Propshaft
- Tailwind CSS
- SQLite
- Self-hosted MP4 video
Technical result
- Server-rendered Rails app with no SPA bundle to hydrate — view source shows the content, not a mount point.
- A detail page for every app in the catalogue, generated from catalogue data rather than hand-built one at a time.
- Interactivity handled by seven small Stimulus controllers loaded over importmap, with no third-party widget scripts in the render path.
- Fingerprinted Propshaft assets, so CSS and JS are cache-busted deterministically on deploy.
Business result
Live, inspectable build. Measured business outcome pending client approval.