When a no-code app needs one complex feature like audio integration, build it separately first. Use a "white room" sandbox to learn the feature's quirks, solve integration problems, then merge it back into your main app clean.
So a really common phenomenon in StateChange Office Hours is people come in, they built a lot of an app, and then they try to introduce the one key feature that turns out to be the cornerstone of the whole app and is also severely more technically complicated than all the rest of it. And they're now trying to stack that onto the rest of the app. And they're having all sorts of challenges, right? The thing they're trying to bring in is itself complicated, like trying to bring audio in. That's a really classic example of a hard thing to do in a lot of these apps. And the— and they're trying to bring the audio and it's not quite working and not really sure which intersection is causing problems. My recommendation to you is that when you discover you have a new and complicated or hard to work with subsystem, stop, open a new project and create what I call a white room, which is a project that's only going to be about dealing with this one feature and learning about it, getting control over it before you integrate back into your app. I find that approach often used by reverse engineers can make a huge difference.
