Building a music visualizer from scratch: what we learned launching Novus Visualizers

The concept behind Novus Visualizers is simple enough to state in one sentence: give music creators a way to produce a branded video asset from their audio without fighting a production tool that was designed for something else. Executing that concept in a way that actually works for real users is considerably less simple. This is a retrospective on the decisions we made, the things we got wrong on the first pass, and what the process of launching an MVP taught us about both the product and our own assumptions.

Music visualizers as a category already had existing tools when we decided to build in this space. The question was not whether music visualizers existed but whether the existing options matched how our target users actually needed to work. The answer, based on early research, was that most options were either too simple to produce a branded result or too complex to use without a significant time investment that killed the benefit of having a fast visual asset pipeline. The gap we aimed at was in the middle: powerful enough to produce something distinctive, simple enough that a creator could complete it in a single focused session.

The first major design decision was the upload-first interaction model. Rather than asking users to build a scene from scratch and then attach audio, we inverted the flow: upload the audio first, let the app analyze it for beat and amplitude data, and then present visualizer options pre-fitted to that audio's characteristics. This inversion changed the creative experience substantially. Users were not staring at a blank canvas trying to imagine how their music might fit into a scene — they were choosing between options that already felt responsive to their specific track.

The second major decision was the definition of "done" for the MVP. We defined done as: a user who has never seen the app can upload a music file, configure a visualizer to their satisfaction, and export a video file that is ready to post without additional processing, in a single session without needing help. That definition ruled out several features that would have made the product feel more impressive in a demo — real-time preview without buffering, multi-track composition, custom waveform designs — while keeping us focused on the features that made the core workflow reliable.

Building with a small team means making tradeoffs that a larger team with more time would not need to make. The most consequential architectural decision in the Novus Visualizers MVP was committing to client-side rendering and export instead of a server render farm. Everything runs in the browser: the Web Audio analysis, the WebGL and Three.js render, and the final encode. We export through the WebCodecs API to MP4 (H.264) or WebM (VP9), which means there is no upload, no server-side queue, and no per-export infrastructure cost. The track and the finished video never leave the device. For a free, ad-supported tool run by a small team, that property is not only a privacy stance — it is what makes the unit economics work at all, because the marginal cost of an export is paid by the user's own hardware rather than a GPU bill we would have to cover for every render.

The tradeoff we accepted is that export performance is bound by the user's device. A capable machine encodes a 4K visualizer quickly; a modest laptop takes longer on the same scene. We leaned into that constraint rather than fighting it. Platform-specific export presets — YouTube 16:9, TikTok and Reels 9:16, square, and others — cap resolution and frame rate to sensible targets so most exports finish in seconds rather than minutes, and the interface communicates render and export progress clearly in-app so a creator always knows where their video is. A server pipeline would have removed the device dependency but reintroduced uploads, a processing queue we would have to operate, and a recurring cost per video — exactly the things the client-side approach was chosen to avoid. The MVP shipped on the side of keeping the work local and the experience immediate.

The biggest assumption we got wrong was about default settings. We built the app with conservative defaults — low saturation, moderate animation intensity, neutral color palettes — on the theory that users would prefer to start subtle and add intensity. Early users consistently reported that the defaults felt dull and that they expected more visual impact before any configuration. We updated the defaults to be more energetic without making them overdesigned, and the first-session completion rate improved measurably within the first two weeks after that change.

We also underestimated how much guidance users needed about the file format requirements for audio upload. Our original onboarding assumed users would understand which file formats were supported. They did not, and the resulting upload errors were the single largest category of support requests in the first month. Adding a clear file format note directly adjacent to the upload interface — not buried in help docs — reduced those support requests by more than half before we had even improved the error handling. The lesson is that information users need at the point of action belongs at the point of action, not in documentation they have to seek out.

The most valuable thing about an honest product retrospective is that it surfaces the difference between what you thought you were building and what users actually needed. We thought we were building a tool for musicians who needed a visual complement to their audio releases. What we discovered is that the most enthusiastic early users were not musicians finishing albums — they were content creators who needed branded visuals for social media and promotional use, where the music was secondary to the visual identity. That shift in primary user profile changed some of our roadmap priorities, specifically around export format flexibility and branding customization options.

The core upload-edit-export workflow held up well through the launch period, which validated the narrow scope decision. Users who completed the core workflow were significantly more likely to return than users who hit friction before completing it. That pattern confirmed that the right growth lever for Novus Visualizers is making the core loop more reliable and faster, not adding adjacent features before the center is solid. We are building from that foundation, and this retrospective is the honest accounting of how we got to where we are starting from.

Building a product with a small team under real time constraints requires a degree of process discipline that is different from, not lighter than, what a larger team needs. The most important process elements are a short, actionable task list that everyone can see and a clear decision owner for blockers. Without the task list, work fragments across people and progress becomes invisible. Without a decision owner, blocked tasks stay blocked because everyone assumes someone else is resolving it. These two elements — shared visibility and clear ownership — are the minimum process infrastructure that makes a lean build cycle function.

Everything beyond those two elements should be evaluated on whether it accelerates the build or adds coordination overhead that slows it. Daily standups, sprint planning rituals, and multi-layer approval processes all carry a cost in time and context-switching that a small team cannot always absorb. The right process for a lean build cycle is the lightest version that keeps work moving and problems visible without requiring more coordination than the team has capacity for. For Novus Visualizers, that meant a shared task board, a clear priority ordering, and a weekly review of what shipped and what was next — no more, no less.

Hindsight produces clearer product advice than foresight, and this retrospective would be incomplete without the specific things we would tell the team at the beginning of the Visualizers build. First: define "done for the MVP" in user outcome terms before writing a line of code. Not "this feature is implemented" but "a new user can complete the core workflow in a single session without help." That definition would have ruled out some early scope additions and kept the first release tighter.

Second: test the onboarding experience with someone who has never seen the product as early as possible. The assumptions that embedded themselves into the default settings and the file format guidance would have surfaced in the first week of external testing rather than in the first month of production support. The temptation to delay external testing until the product "feels ready" is understandable but consistently expensive. It delays the most valuable signal — how real users encounter the product for the first time — in favor of a level of polish that real first-time users will not notice but that internal familiarity makes feel important. Ship to an external test user sooner than feels comfortable, and adjust based on what you learn.

Music visualizers were not an empty category when we decided to build Novus Visualizers; existing tools already occupied the space, which raises the obvious question of why build another one. The answer is that the existing options clustered at two unhelpful extremes relative to how our target users actually needed to work: either too simple to produce a result distinctive enough to feel branded, or too complex to use without a significant time investment that killed the entire benefit of having a fast visual pipeline. The gap we saw was not the absence of music visualizers but the absence of one positioned in the middle — powerful enough to produce something distinctive, simple enough to finish in a single focused session.

Building in a crowded category is justified when you can identify a genuine gap in how the existing options serve a real need, rather than when you simply want to compete on the same axis as everyone else. Our research into how creators actually used visualizer tools revealed that the existing options forced a bad choice between triviality and complexity, leaving the creators who needed a fast branded result underserved. That gap, not the mere existence of the category, is what made building worthwhile. The lesson is that a crowded category is not a reason to avoid building; it is a reason to be precise about the specific gap you are filling, because building another tool that occupies the same position as the existing ones would have been pointless, while building one that fills a real gap in how the category serves users is exactly the kind of opportunity a crowded category can still contain.

The most consequential architectural decision in the Novus Visualizers MVP was committing to client-side rendering and export rather than a server render farm, and this bet shaped everything else about the product. Everything runs in the browser — the Web Audio analysis, the WebGL and Three.js render, the final encode through the WebCodecs API to MP4 or WebM — which means there is no upload, no server-side queue, and no per-export infrastructure cost. The track and the finished video never leave the device. For a free, ad-supported tool run by a small team, this is not only a privacy property but the thing that makes the unit economics work at all, because the cost of each export is paid by the user's own hardware rather than a GPU bill the operation would have to cover for every render.

The bet carried a real tradeoff that we accepted deliberately: export performance is bound by the user's device, so a capable machine encodes quickly while a modest one takes longer on the same scene. We leaned into this constraint rather than fighting it, using platform-specific export presets that cap resolution and frame rate to sensible targets so most exports finish in seconds, and communicating render progress clearly in-app so a creator always knows where their video is. A server pipeline would have removed the device dependency but reintroduced uploads, a processing queue to operate, and a recurring per-video cost — exactly the things client-side rendering was chosen to avoid. Client-side rendering as the defining bet is therefore the decision that everything else about the product followed from: the privacy property, the free-forever economics, and the device-bound performance are all consequences of choosing to keep the work local, which is the architectural judgment that defines what Novus Visualizers actually is.

We built Novus Visualizers expecting the primary user to be musicians who needed a visual complement to their audio releases, and the launch taught us that the most enthusiastic early users were someone else entirely: content creators who needed branded visuals for social media and promotional use, where the music was secondary to the visual identity. This gap between the expected user and the actual user is exactly the kind of discovery that only real usage surfaces, and it is the most valuable thing an honest retrospective can document, because the difference between who you thought you were building for and who actually showed up reshapes the product's priorities.

The shift in primary user profile changed specific roadmap priorities, particularly around export format flexibility and branding customization, because the content-creator user values different things than the musician user we had designed for. A musician finishing an album cares about the music-to-visual fidelity; a content creator building social assets cares about branding control and platform-specific export. Discovering that the actual users skewed toward the latter redirected attention toward the features that serve them. The broader lesson is that user assumptions made during the build are hypotheses to be tested by real usage, not facts to be designed around, because the user who actually shows up frequently differs from the one you imagined, and the product that succeeds is the one that adjusts to the real user rather than continuing to optimize for the imagined one. The user we expected versus the user we got is the single most instructive surprise of the launch, precisely because it could only have been learned from shipping.

The point of an honest retrospective is not reflection for its own sake but the concrete changes it drives, and the Novus Visualizers retrospective changed the roadmap in specific, evidence-grounded ways. The discovery that the core upload-edit-export workflow held up well through launch — with users who completed it far more likely to return than those who hit friction first — validated the narrow-scope decision and confirmed that the right growth lever is making the core loop more reliable and faster rather than adding adjacent features before the center is solid. That confirmation directed post-launch investment toward strengthening the proven core rather than expanding the surface, which is a roadmap decision grounded in the launch evidence rather than in feature ambition.

The retrospective also surfaced specific improvements from where real users struggled: more energetic defaults after early users found the conservative ones dull, clearer file-format guidance at the upload step after format confusion generated the largest share of support requests, and the export-flexibility and branding priorities that followed from discovering the content-creator user. Each of these roadmap changes traces directly to something the launch revealed, which is the testing-lab model working as intended — shipping produced evidence, and the evidence changed what gets built next. What the retrospective changed about the roadmap is therefore the concrete proof that the measurement step is worth doing: the roadmap is a live document updated by what real usage revealed rather than a plan defended against the evidence, and the specific changes the retrospective drove are exactly the kind of evidence-grounded adjustments that distinguish a product that learns from its launch from one that ships and then continues building from its original assumptions regardless of what users actually did.