Building Loopy Demos: from prototype to B2B product

The story behind the Loopy Demos entries on my CV — how a side project became a B2B SaaS product, and the engineering and product decisions that got it there.

Loopy Demos is an interactive demo platform for guitar and bass gear manufacturers. The core is an embeddable widget that lets a visitor hear a piece of gear — a pedal, an amp — right on the manufacturer’s own product page: toggle through knob settings, switch between demos, and mute or solo backing tracks to isolate the sound they care about. Around it sits a blog-like site with editorial content.

I’ve built and run it solo since 2020 — product, engineering, security, analytics, and the client relationships. It has real paying B2B clients, from boutique pedal builders up to Orange Amplification, and it’s monetized both through licensing to manufacturers and through affiliate editorial content. Everything below is one person making the product decisions and living with the consequences.

Starting on Gatsby

I started on Gatsby + React. I already knew React and GraphQL well from my time at XING, so Gatsby’s React-plus-GraphQL model was the fastest way for me to get moving.

From the outset I knew the shape I wanted: a blog-like site with the interactive demo component as a core element, intertwined with static editorial content rather than bolted on beside it. I prototyped the page, recorded the first handful of demos with the gear I owned at the time, wrote the content, and got it ready to publish.

Then I published early and shared the work early — including on Instagram, where the guitar-gear community lives. That “ship it and show it” instinct is what turned a prototype into a product: the site gained traction quickly, and I got into conversations with a few boutique builders. Early on I approached Walrus Audio directly, and they came on board.

Growing by listening

From there the product grew feature by feature, driven by feedback — from the guitar-gear community and from the manufacturers themselves. The additions that mattered most:

an iframe embed with a stripped-down layout, so a manufacturer could drop a demo straight onto their product page;
mutable backing tracks, so a listener can isolate the gear from the mix;
a theming system, so an embedded widget matches the host page’s brand instead of looking like a foreign object;
more editorial content, opening up affiliate marketing as a complementary revenue stream alongside licensing.

The demo catalog grew alongside the widget, and the widget itself got steadily more capable.

One discipline: build for every client, not one

The rule I held myself to throughout: only implement a feature if it could benefit every potential client. When a single customer asked for something specific — a unique control set, or the ability to combine several pieces of gear in one demo — I built it so the capability generalized to other demos later, rather than as a one-off for that account.

That discipline is the whole reason a solo product could keep scaling: every feature request either made the platform more capable for everyone or didn’t get built. It’s the same leverage-over-bespoke instinct behind the multi-tenant monorepo work — say yes to the capability, not to the special case.

Re-platforming to Astro

When Astro emerged as a popular meta-framework for statically generated sites, I recognized the tech/product fit immediately. Loopy Demos is mostly static, content-heavy pages with interactivity in a few concentrated places — exactly what Astro is built for: pure static HTML, content collections organized with a typed schema, and interactive islands that can be written in any framework.

This was before AI coding assistance was a thing, so the migration — effectively a rewrite — was honest coding: sweat, late nights, and doing it by hand on a live, revenue-generating site. I also used it as the moment to overhaul the design.

The site itself wasn’t especially complex, so rebuilding the layout in Astro (Astro’s JSX-like syntax + Tailwind) was the flattest ramp to get rolling. The bigger piece was the interactive widget, which I moved from React to SolidJS.

SolidJS’s reactivity is far easier to reason about for something this stateful. React re-runs a component on every render and asks you to hand-manage what depends on what — useEffect dependency arrays, effects that cascade into other effects, memoization to hold it all together. Solid inverts that: a component function runs once, to set up a reactive graph, and after that only the fine-grained pieces that actually read a changed value re-run. Dependencies aren’t declared — they’re discovered at runtime, by tracking which signals get read inside a reactive scope.

The demo widget is exactly the case where that pays off: multiple knob states, audio pre-fetching and loading, playback kept in sync, audio-player state — highly interactive, with a lot of interdependencies. Moving it to Solid’s model shrank the code dramatically: the SolidJS rewrite came out to roughly a quarter of the line count of the React version, with far less accidental complexity holding it together.

This migration is also why I was trusted to drive an Astro-based company website at Whiskey Tango Foxtrot — the experience was directly transferable.

Streamlining the workflow

After the migration I kept streamlining the production workflow, scripting everything repeatable: audio conversion, file scaffolding for new demos, image processing, and video generation for social media. That’s what makes a one-person catalog sustainable — the marginal cost of publishing another demo keeps dropping.

Making embedding effortless — and the payoff

I intentionally made the widget as easy as possible to embed as an iframe — partly as a growth bet, in the hope that other potential clients would stumble across it in the wild and discover Loopy Demos organically.

That’s exactly what happened when Orange Amplification approached me — my first substantial B2B client. Loopy Demos became their standard way to showcase how their gear sounds, directly on their product pages.

A client of that caliber brought new requirements — most notably, connecting Loopy Demos analytics to their own analytics suite. I built the first iteration on the browser’s postMessage API, emitting key widget events (playback, demo switches, control changes) so the host page can listen for them and correlate widget engagement with everything else it tracks — potentially, whether engagement correlates with buying behavior.

Analytics, and closing the loop

That client request is what pushed me to integrate a proper analytics suite into Loopy Demos itself. I chose PostHog — in part because its tooling is genuinely good for an agent-driven workflow (its own AI wizard, an MCP server, and a Claude Code plugin).

Honestly, I should have done this years earlier: it’s the difference between making product decisions on qualitative signal alone and being able to back them with quantitative data. I now run a suite of dashboards and insights — and can share a comprehensive, credible view of engagement with clients, which is itself part of the pitch.

What this shows

Loopy Demos is the clearest evidence I have of owning a product end to end rather than implementing someone else’s spec: I chose the stack and re-chose it when the fit changed, drew the line on which features earned their place, made the security and analytics calls, and carried the client relationships. The engineering only mattered because it stayed in service of a product that had to earn real revenue from real customers.