From slow and heavy to fast and light

Who Was the Client?

AG Watermark Generator is a desktop tool for musicians, composers, producers, and sound designers that lets them add voice and audio watermarks to their tracks — protecting beats, demos, and edits before sharing them online. Available for Mac and PC, with text-to-speech tags, preview, and batch processing.

The product is made by AGsoundtrax, LLC (Austin, Texas), and was built by its founder — a composer with over two decades of experience writing music for film, TV, and multimedia, with an established following/community of his own. He needed a fast, reliable way to protect his own tracks when sharing demos and submissions with clients and licensing platforms, couldn't find a simple batch-watermarking tool on the market, and built one himself.

The client came to Synterra with an AI-assisted (vibe-coded) build of the product — technically functional, but not yet launched, with engineering gaps standing in the way of a real production release.

What Was the Client's Request for Collaboration?

The app already worked — users could add watermarks and convert audio files. But it was built quickly with AI tools, without a professional engineering foundation, and it was starting to show:

• • Slow processing, built on WebAudio

• • A bloated install size (~1 GB)

• • Bugs in conversion, watermark application, and UI responsiveness

• • Instability when handling multiple files at once

The client asked Synterra to take this AI-generated codebase and bring it up to production quality — without changing what it already did.

Main Goals

• • Refactor and optimize the existing codebase for performance, stability, and maintainability

• • Replace WebAudio with FFmpeg to speed up audio processing

• • Reduce the overall project size to improve installation and load times

• • Optimize the app's workflow for handling multiple files efficiently

• • Fix critical bugs affecting conversion and watermark features

• • Preserve a smooth, offline-first desktop experience throughout

The engagement ran about six weeks (Sep 29 – Nov 12): the team took over the client's existing code, audited how it was actually built (vs. how it was assumed to work), and reworked it piece by piece.

What Was the Client's Bigger Business Goal?

Turn a fragile, AI-built product into one that musicians can actually depend on. AGsoundtrax positions the product as a simple, no-bloat, professional tool "designed for musicians, by a musician" — a stable, fast, lightweight app supports that positioning directly.

At What Stage Was the Client's Project?

The client already had a functional build — the vibe-coded version could add watermarks and convert files. What it lacked:

• • A production-grade audio processing pipeline (WebAudio wasn't built for this at scale)

• • A reasonable install footprint (~1 GB)

• • Stability under real-world multi-file workloads

• • Bug-free conversion and watermark features

Starting point: a working idea proven by AI-assisted development — but not yet launched, with no real users, and not an engineered, shippable product.

What Was the Expected Outcome?

• • Refactored, production-ready codebase

• • Faster audio processing via FFmpeg

• • Dramatically smaller install size

• • Reliable handling of multiple files at once

• • Critical bugs resolved across conversion and watermark features

• • All existing functionality preserved, offline-first experience intact

How Was the Result Measured?

Technical validation:

• • Processing speed: converting a 3-minute audio file dropped from 50 seconds to 3 seconds after the WebAudio → FFmpeg migration

• • Project size: reduced from 1 GB to 180 MB

• • Stability testing under multi-file load

• • Verification that critical bugs (conversion, watermark, UI responsiveness) were resolved

The product had not yet launched at the start of the engagement, so no adoption/revenue metrics existed to benchmark against — success here was defined by production-readiness itself.

How Did the Collaboration Work?

The client came in with a defined set of requirements — refactor the codebase, migrate off WebAudio, cut the install size, fix known bugs. During discovery, the team tested the existing app against those requirements and found that several features the client believed were working correctly either behaved incorrectly or didn't work at all.

Rather than just addressing the original list, the team tested and fixed those hidden issues as part of the engagement — so the client got a fully verified, working product, not just the specific fixes they'd asked for.

The UI froze during processing

Converting and watermarking files ran on the main thread, so the entire interface locked up and became unusable while a file was processing.

Solution: Moved processing to a background thread and rebuilt the audio pipeline on FFmpeg — the app stayed responsive no matter what was running.

Processing wasn't actually backgrounded, despite what the client believed

The client's brief described the app as working correctly, just slowly, and assumed processing already ran in the background. Testing showed it didn't — everything ran synchronously on the main thread, which was the actual cause of the freezing.

Solution: Diagnosed the real cause during discovery and re-architected the processing flow, rather than just optimizing the existing (flawed) approach.

Fixing one feature broke another

The codebase was fragile enough that isolated fixes had ripple effects elsewhere in the app.

Solution: Rebuilt the affected logic with proper structure instead of patching symptoms one at a time.

Dead code throughout the codebase

The existing code included a lot of leftover logic that did nothing, making it harder to tell what was actually running.

Solution: Audited the codebase during discovery to separate working logic from dead weight before refactoring.

OS-specific packaging

Bundling the right libraries correctly for each operating system (Windows/macOS) required platform-specific packaging work.

Undocumented audio configuration and edge cases

The audio processing involved many specific, undocumented settings and edge cases that had to be discovered and tested individually to avoid regressions.