Building KahuStack: Learning to Make Software That Cares for the Work

KahuStack did not begin with a perfectly formed product idea.

It began with a desire to build a reusable foundation for web applications: something I could understand deeply, deploy confidently, and use as the starting point for real production software. I wanted an application stack that could handle accounts, authentication, email, media, APIs, permissions, and all of the other systems that quickly turn a simple idea into a serious application.

For a long time, WordPress was my natural starting point. It has been my go-to publishing and content management system for years, and I still think it is one of the best tools available for business websites and professional publishing workflows.

I experimented with several ideas around it. ChordCrate was intended to manage MIDI libraries and help explore chord progressions. Feedwise was a private feed reader and news aggregation system. An earlier project called Prism used WordPress as an application runtime, leaning on its database, user system, and email functionality.

Those experiments taught me a lot, especially about where the boundaries of an application should be. But the deeper I went, the more the systems began to feel improvised rather than purpose-built. They worked, but they did not feel like the scalable, commercially viable application foundation I was trying to learn how to create.

I wanted to understand how to build software that could potentially handle a large amount of user-generated content and a significant number of users without feeling like it was being held together by adaptations and workarounds.

That eventually moved my attention toward Cloudflare Workers and the collection of primitives around them.

Finding a Foundation

I could probably compare infrastructure providers forever.

Cloudflare, AWS, Google Cloud, DigitalOcean, a traditional server, a collection of managed services—there is always another architecture to research and another benchmark to run. I enjoy that process, perhaps a little too much. There is always some new combination of tools that looks promising.

But I am not getting any younger.

The last half year—or probably longer—has involved a huge amount of learning and experimentation. At some point, continuing to compare every option stops being careful research and starts becoming a way to avoid committing to the work.

Cloudflare eventually became the foundation because its infrastructure felt aligned with what I wanted to build. Workers are widely available, deployment is fast, the developer experience is good, and the surrounding services provide a coherent way to think about databases, storage, caching, images, queues, and application delivery.

More importantly, I have finally settled into a set of tools and patterns that feel comfortable.

I still plan to use WordPress for blogging and publishing. KahuStack is not a rejection of it. It is the production application stack I wanted alongside it: a foundation for interactive public-facing software, user accounts, private data, media workflows, and tools that would be awkward to force into a traditional CMS.

That foundation was the original goal. Audio gave it a reason to exist.

The Mess Around Creative Audio

Collecting feedback on music has always been a mess.

A file gets attached to an email. Another version gets sent later. Someone downloads the first one but misses the second message. A client writes a page of notes while listening to an older mix. The timestamp in the note may or may not correspond to the same version you have open.

Sometimes the file is on one computer while you are somewhere else. Sometimes you want to send a friend a link so they can test a mix in their car, but the file is inaccessible while you are already driving. Sometimes the feedback exists in one email thread, the lyrics are somewhere else, and the final version is sitting on a flash drive.

None of these problems is individually dramatic. Together, they create friction around work that people have often spent months or years making.

My mom is one of the people I think about while building KahuStack. She is an accomplished songwriter with a large body of work—more than sixteen albums, I think, although I do not even know the exact number. Despite all of that work, there is no single definitive place where all of her music lives.

That seems like a problem worth solving.

She is also a band leader and regularly needs to share recordings, reference tracks, charts, lyrics, and printable material with musicians. Some songs have a final mix, a backing-track version, and a “minus one” version without background vocals. Many of her songs are written to be performed by other people and should be accompanied by lyric sheets, chord charts, tabs, or other supporting documents.

There is also the matter of her mix notes.

Anyone who has seen them would immediately understand some of my motivation. They can resemble a scattered constellation of chicken scratch, accompanied by timestamps that may or may not be accurate and handwriting that may or may not be decipherable.

I say this with love, Mom.

Being able to click directly on a waveform, select a moment or range, and leave a clearly positioned note would make my life as an audio engineer substantially easier.

More importantly, I do not want her work—or anyone else’s—to remain scattered. It deserves a place where it can be preserved, understood, and presented with care.

From Files to Presentation

Music used to arrive as an object.

Albums had covers, liner notes, credits, photographs, typography, sequencing, and physical presence. Even a homemade CD or cassette could feel like a complete package. The presentation communicated that someone had cared about the work.

A great deal of music is now passed around as a file.

That file may end up in a downloads folder, on a flash drive, inside an email thread, or buried in a cloud storage account. The artwork and liner notes are separated from it. The context disappears. The song becomes one more anonymous object on a hard drive.

Not every musician has the knowledge, time, or resources to build a custom website for every project. Existing platforms can help, but their branding, recommendations, advertising, and engagement systems often compete with the work itself. A song can feel like one small item in an endless sea of content.

I want KahuStack to offer a more focused experience.

The goal is not to surround the work with KahuStack branding. It is to give the work enough structure that it can speak for itself.

That idea is part of the name.

The Hawaiian word kahu has several meanings. I did not choose it as a reference to the translation sometimes associated with a pastor. I chose it because of its relationship to care, guardianship, responsibility, and trust.

KahuStack should care for the work placed inside it.

That means preserving files properly, communicating system state honestly, giving creators control over what is shared, and treating the user’s work as something to protect rather than something to exploit.

Preserve the Original

One of the clearest principles in KahuStack is that the original uploaded audio should be preserved.

Web playback may require derived encodings. A preview file may be useful. Someone may want to generate an MP3 with artwork and metadata for delivery. Those outputs have value, but they should not replace the source.

Preservation matters because fidelity matters. Authorship matters. The original file represents the material the creator trusted the system to hold.

KahuStack is here to care for that work, not consume it, rewrite it, or trap it.

This principle has also helped clarify the product model. An audio entry can have multiple versions, each representing a meaningful uploaded source: a latest mix, a timing fix, an acoustic version, an alternate take, a backing track, or a revised podcast edit.

A song, podcast episode, or musical arrangement can add its own metadata and publishing behavior, but the underlying audio remains stable. Generated delivery files are outputs, not replacements.

It sounds simple when written down. Arriving at simple ideas often requires a surprising amount of iteration.

A Lot of Small Decisions

I have rebuilt a great deal of KahuStack.

The database schema has changed repeatedly. I have experimented with custom compact waveform peak formats, application shells, responsive behavior, design systems, and frontend frameworks. I have reconsidered authentication boundaries, media ownership, API response shapes, and whether different services should share one database or use several.

There are decisions about SQLite, local storage, authorization, metadata stripping, image handling, transactional email, subdomains, server-side rendering, static pages, single-page applications, notification fanout, API contracts, DTOs, OpenAPI documentation, caching, and error codes.

I constantly have Chrome DevTools open to watch performance and inspect network requests.

Should a profile image URL live in the user table provided by the authentication library, or should account media have its own table? Is the cleaner model worth an additional database call? Should media be processed on the server, in a container, through a managed service, or directly in the browser?

At one point, I experimented with server-side audio processing through FFmpeg in a container. It worked, but it quickly became clear that the operational cost and complexity were not justified for the project at this stage.

That helped reinforce a broader direction: simple is often better, and an edge-native application should make thoughtful use of the browser.

This does not mean shipping enormous JavaScript libraries or making every user’s device do unreasonable work. It means recognizing that modern browsers are capable media-processing environments. Some tasks can happen locally, preserve privacy, eliminate server costs, and make the application feel faster.

The architecture is increasingly guided by practical boundaries instead of theoretical purity. Build what is needed. Reduce unnecessary database calls. Keep APIs fast. Preserve portability. Avoid expensive infrastructure until a real use case requires it.

Uploading Without the Upload Screen

One part of KahuStack that currently feels especially successful is the optimistic audio upload and handoff experience.

When someone selects an audio file, the track appears in the library immediately.

The system does not send the user to a detached upload screen and ask them to wait. It creates an optimistic library item while the upload continues in the background. The interface can show the filename, artwork, progress, and an initial waveform state almost immediately.

The waveform is generated as soon as the file is selected. Embedded artwork can be detected and used to populate the artwork field. Playback can begin before the upload has completed.

Once the source has been securely handed off to storage, the temporary local state is replaced by the completed library item. That transition does not interrupt playback or reset the listener’s position.

The result feels less like submitting a file to a server and more like placing something directly into your library.

That distinction matters to me. A good interface should not make the mechanics of an upload feel more important than the thing being uploaded.

The Waveform Side Quest

Waveform rendering has become its own significant area of experimentation.

The current side project is called KahuStack Waveframe. The name was suggested by AI, so blame the machine for any hokeyness.

Waveframe is an attempt to create a responsive, precise waveform system that can appear immediately, remain smooth across long recordings, and eventually support demanding environments such as very large audio libraries or multitrack interfaces.

Instead of drawing an entire audio file at maximum detail, it uses virtualized, level-of-detail rendering. A compact overview can appear first. As the user zooms or moves through the recording, the renderer selects the amount of peak detail appropriate to the visible region.

Only the portion the user can see needs to be rendered at full detail.

The goal is to support smooth playback, scrubbing, timeline annotations, region selection, and precise zooming without wasting memory and processing power on audio that is currently offscreen.

Waveframe is still in development. It is also exactly the kind of problem I probably would not have explored as deeply without AI.

Mathematical implementation is not my strongest area. AI has made it easier to experiment with shaders, animation, compact binary formats, virtualized rendering, and performance strategies that would otherwise require much more time to prototype.

That has been one of the most valuable parts of this process.

Building With AI, Carefully

AI has helped enormously as a research assistant, implementation partner, and sounding board.

It makes it possible to clone a repository, try an unfamiliar package, deploy an experiment to Cloudflare Workers, stress-test an idea, and learn from the result much faster than I could on my own.

It is especially useful for scaffolding, mathematical code, quick prototypes, and comparing approaches.

It is not a substitute for understanding the product.

When I am tired, skip planning, and lazily ask an agent to “create the feature,” bad news generally follows.

AI can produce something technically impressive that does not follow the project’s intended patterns. It can invent unnecessary abstractions, misunderstand domain boundaries, or solve the visible problem while creating several invisible ones.

At one point, we experimented with a vector database for managing project knowledge. It was interesting. It was also probably excessive.

These failures have been useful because they have forced me to become more precise. I now spend considerably more time describing intended system behavior, product boundaries, architecture rules, and data ownership before asking AI to implement anything.

AI has not removed the need for product thinking. It has made unclear thinking more expensive and clear thinking more valuable.

Why KahuStack Is DAW-Adjacent

KahuStack is not intended to replace a digital audio workstation.

Part of the reason is practical: building a complete edge-native DAW would be an enormous undertaking.

The more important reason is that creators already have tools they prefer for recording, editing, mixing, and mastering. Competing with those tools is less useful than improving everything that happens around them.

KahuStack can focus on audio utilities, version management, presentation, collaboration, publishing, storage, and feedback. It can help archive project files, stems, mixes, and supporting material without trying to become the place where every production decision must be made.

There may eventually be lightweight editing, trimming, recording, metadata preparation, and delivery tools. But the center of the product is the audio that has entered a sharing, review, preservation, or publishing lifecycle.

It is the space between the production session and the audience.

Where It Is Now

A lot still feels unfinished.

The application foundation is largely in place. Account lifecycle, transactional email, the frontend shell, and the major technology choices are established. I am now focused on hardening those systems and making the architecture more robust.

Image handling is in good shape, helped substantially by Cloudflare Images. Basic audio presentation features are close. Uploads and library management are functional.

The Audio Library schema is still evolving, and staying focused can be difficult. It is tempting to disappear into a rabbit hole involving presentation design, rendering techniques, animations, or waveform performance before the storage rules and core data structures are completely solid.

But when I open KahuStack on my phone and my audio is there, it feels good.

Uploads are fast. Playback works. The idea is becoming real.

That moment does not erase everything that remains to be done, but it changes the character of the work. KahuStack is beginning to feel less like a collection of experiments and more like a product.

Worth Building

I hope other people eventually use KahuStack.

I hope musicians find it useful. I hope engineers use it for client feedback. I hope it gives music like my mom’s a permanent and thoughtfully presented digital home.

Realistically, some clients may continue emailing me files. My mom may continue handing me constellations of chicken scratch. Software can only solve so much.

But the project is already worthwhile because of what building it has taught me.

I now have a production stack I understand, a clearer sense of the systems I want to build, and a growing collection of tools and patterns that can support future ideas. I have learned more about application architecture, media handling, product design, performance, documentation, and domain modeling than I could have learned by only reading about them.

The destination remains uncertain, but the principles are becoming clearer.

Preserve the work. Respect the creator. Keep the interface focused. Use technology carefully. Avoid extracting value from the people the system is supposed to serve. Build the simplest system that can care for the material properly.

And keep enjoying the process of watching a thought slowly become something real.