Drop any sound, instantly.

[sage]SOUNDS is a soundboard for live situations. Upload audio, map it to a pad, and trigger it instantly — without breaking your flow.

The problem it's solving is small but specific: in meetings, streams, or calls, there's no easy way to drop a sound at exactly the right moment. Most options require switching apps, fumbling with files, or setup that slows you down. [sage]SOUNDS keeps it out of the way.

Since this started as an experiment, my initial requirements were very simple. All I really needed were keys mapped to sounds.

The first version of [sage]SOUNDS (which didn't even have a name yet) used a full QWERTY keyboard layout. Technically it worked, but it felt too busy and cluttered. I eventually switched to a 14-pad numpad-style grid instead. It felt cleaner, worked better on mobile, aligned naturally with desktop numpad keys, and was immediately familiar to most people.

Custom audio uploads were always the core feature. Generic sounds are fine for testing, but the app only really comes alive once people can upload their own sounds. That decision introduced a lot of unexpected complexity, especially around iOS Safari where audio playback rules are extremely strict. Getting it to work consistently across browsers and devices required several different approaches before landing on something reliable. I also added a 1MB upload limit to stay within the constraints of the free infrastructure the app runs on.

Next up was authentication. Supabase handled the basic sign-up and sign-in flows, but I also wanted to add Google OAuth since it removes a lot of friction during registration. Since this was meant to be a portfolio project, I knew I also wanted people to experience the app immediately without needing to create an account. That led to building the demo version of the board. After that came the auth page, along with the About page (what you're reading now) to better explain and showcase the project.

Then came a full UI cleanup pass across the entire app: authentication flows, boards, board settings, layouts, and interactions. I tried to simplify as much as possible.

At that point, I felt like the project was in a pretty good place, but I had already built up a backlog of ideas and couldn't stop myself from continuing. One board worked well, but I realized people might want different sets of sounds for different meetings, friend groups, or use cases. That led to multi-board support. I eventually settled on a limit of three boards as a good balance for free-tier usage.

Custom image icons started as something funny for me. I wanted to create a board with photos of my friends paired with audio clips of phrases they constantly say. But once I started scoping it out, it turned into a much larger feature than I expected — image uploads, cropping, cloud storage, rendering logic, and multiple UI states to handle cleanly. That ended up being one of the more interesting lessons from the project. Small ideas that seem unnecessary at first can sometimes become the features that make a product feel more personal and complete.

Shareable boards came from a simple question: what's the point of building something this personal if you can't show it to anyone? The implementation turned out to be more involved than I expected — generating share tokens, proxying private audio so files stay protected, and making sure the shared view felt just as polished as the owner's. A lot of the technical work to get it running reliably was done with Claude Code, but the decisions about what to build, how it should feel, and where to draw the line were mine.

Once all of that was in place, I did another cleanup pass across the entire app. I also had Claude Code help generate unit and functional tests, along with a proper deployment checklist, before doing one final full pass.

There were plenty of other smaller decisions and tradeoffs along the way, but that's part of what made the project interesting. Every feature introduced a new set of problems to solve.

The current version looks nothing like V1, which honestly feels like the point. A lot of ideas never made the cut — MIDI support, in-app audio recording, and a bunch of other things I considered early on. One of the biggest lessons from building this was realizing how important it is to know what not to build, especially when you're iterating quickly.

I also intentionally kept the entire stack on free infrastructure tiers. My mindset was simple: if nobody is using the product yet, there's no reason to overcomplicate things or spend money too early. Build something functional, learn from it, improve it, and keep moving.