a question that comes up every couple weeks: are you going to add a button to keep one of the flowy tracks as a single song? a "save this as a finished song", maybe with a way to edit the lyrics or extend the bridge.
the answer is no. not because we couldn't (the underlying model can), but because that's a different product and we don't want to be that product. this piece is the longer version of why.
the obvious version
suno and udio exist. they are good at single-song iteration. if you want a single song you can edit, save, extend, and release, those are the tools. flowy can't out-suno suno on suno's home turf, and even if we could it would take years.
the obvious version of the answer is also the right one, most of the time. don't fight tools that have a one-year head start in a category you don't actually care about.
the less obvious version
the more interesting reason has to do with what you're optimizing for. flowy is optimized for one specific moment of failure: the moment your background music annoys you. every product decision flows from making that moment less frequent and less painful.
adding a "save this song" button creates new product surface that competes for that same optimization budget. the iteration loop (tap save, tap edit, tap regenerate the bridge) is ergonomically wonderful for creators and terrible for listeners. it pulls your attention back to the music, which is the exact attention-pull we're trying to eliminate.
you can have a save button or you can have a stream that keeps going. you can't have both as the central thing.
the structural version
even more structural: a stream that keeps going implies the next track exists and is already being prepared. a saveable song implies the current track is the deliverable. one of these has to be the primary mental model and the other has to be secondary.
if "current track is the deliverable" wins, the stream becomes a queue. queues are a different shape with different affordances; people want to reorder, skip, save, share, and re-queue. you end up rebuilding spotify.
if "stream that keeps going" wins, the current track has to be ephemeral. it's not a deliverable. it's a moment you passed through. you can't save it any more than you can save a particular wave in the ocean. (you can record it. we let you do that. but the recording is a souvenir, not the product.)
what we'll do instead
the way you keep a flowy track today is downloading it as an MP3 (paid per-track or included in the subscription). that's a deliberate friction. the MP3 is a souvenir of a moment that passed; it's not the product. people who want it can get it. people who don't are nudged toward not making the save mental model the dominant one.
what we'll keep building toward:
- better cache hits. first track instantly on any reasonable scenario.
- smoother retunes. no audio bump when you shift from one mood to another.
- better genre fidelity. when you ask for afro house, the stream should be unambiguously afro house.
- shareable sessions. so someone can listen to the same scene you were in.
- more languages and locales.
- cheaper streaming so the unlimited tier prices aggressively.
all of those compound on "stream that keeps going". none of them help "save this song". keeping the optimization budget focused matters.
the meta-version
most early-stage tools die from feature sprawl. people ask for things, the tool says yes, the central thing it does well gets diluted, the people who came for the central thing leave, the tool is now mid at everything.
the "save this song" button looks like a small ask. it isn't. it's a structurally different product asking to be born inside the current one. that's exactly the kind of request to say no to.
if you want a song to keep, suno is great. go use suno. flowy will still be here when you want to put music on and forget about it.