Overview
Musicaguide is a VST3/AU audio plugin, written in C++ with the JUCE framework, that runs inside any DAW as a side panel. You ask it mixing, mastering or sound-design questions in plain English and it gives concrete moves — EQ curves, compression settings, effect choices — rather than vague advice. I produce music, so the problem was one I actually had: the answers exist somewhere on a forum, but not while you're mid-session with the track in front of you.
The Problem
Two problems, and the second one is the real engineering one. First: audio production advice is scattered across forums and videos, none of it aware of what you're currently working on. Second, and harder: any AI tool with a per-user inference cost dies the moment it gets popular — you either eat an unbounded API bill or you gate everything behind a subscription before anyone has a reason to pay you. I wanted an architecture where shipping to ten users and shipping to ten thousand cost me exactly the same: nothing.
My Approach
Bring-your-own-key. The user enters their own API key in the plugin's Settings panel, and it's stored in the operating system's credential store — Keychain on macOS, Credential Manager on Windows. It is never hardcoded, never committed, and never sent to any server of mine. That single decision drops hosting cost to $0 and makes the user count irrelevant. But I didn't want to be locked into it forever, so every network call goes through a thin provider/HTTP abstraction: a hosted freemium proxy (free tier + usage analytics) can be added later without touching a single line of the UI. The plugin talks to any OpenAI-compatible endpoint — configurable base URL and model — so it isn't married to one vendor either.
Technical Implementation
C++ with JUCE, built via CMake. The plugin builds as VST3, AU and Standalone, and CI covers both platforms on every commit: a macos-14 runner producing a universal binary (x86_64 + arm64) and a windows-latest runner. Actions are pinned by version, the workflow runs with least-privilege permissions (contents: read), JUCE is cached between runs, and no secrets exist anywhere in the pipeline — because there's nothing to inject. The only key in the source tree is a Supabase publishable key behind insert-only row-level security, which is public by design. On top of that sits a freemium scaffold: free-tier usage limits, anonymous usage-analytics hooks, and pro features stubbed behind a gate for a later paid upgrade.
Results
The plugin loads in a DAW and answers questions about the session, and CI produces installable macOS and Windows artifacts from a single push. The architecture goal held: there is no per-user cost, so distribution is unconstrained. Being straight about where it stands — the builds are currently unsigned (I deferred code signing and notarization), so macOS users get an 'unidentified developer' warning on first open, and it hasn't had a public release yet. Signing, a landing page, and wiring download buttons to the release artifacts are the remaining steps before launch.
What I Learned
The cost architecture mattered more than the model. I spent far more design time on where the API key lives than on prompting, and that was the right split — BYOK plus a provider abstraction is what turns a demo into something that could actually ship to strangers without bankrupting me. I also learned how much of shipping desktop software is not the software: cross-compiling a universal binary, getting JUCE to cooperate with CMake on two operating systems, and the fact that code signing and notarization are a real project in their own right, not a checkbox at the end. Writing C++ after mostly living in Python was its own reset — no garbage collector, and a real-time audio thread that will punish you for allocating on it.