How we read the first wave of feedback
When a studio site goes live, a particular flavor of email starts to arrive. Not bug reports about a specific app — those have their own channel — but bigger, vaguer feedback. I’d love an app that does X. Have you considered Y? Your pricing is too low / too high / unclear. All of it is a gift. Most of it can’t become product.
That last sentence sounds harsher than we mean it. The problem isn’t the quality of the suggestions; many of them are good. It’s that a small studio can only build a few things at a time, and every yes is a no to something else. So the real work is deciding which handful of ideas deserve that space.
What we do with it
Read it. Tag it. Sort it. Suggestions go into a shared document we re-read at the end of every quarter, not every week — the patterns that matter become visible only when you have enough of them to see a trend.
The tags are simple: which app it’s about (or “studio” if none), what kind of request it is, and a one-line paraphrase in our own words. The paraphrase matters. Writing down what we think the person actually needs, rather than the solution they proposed, is often where the useful insight appears. Someone asking for a calendar export in a wedding planner may really be telling us they share the planning with someone who doesn’t use the app.
We reply to everyone, even if the reply is short. A brief thank-you with an honest note — “this is on our list,” or “this probably isn’t something we’ll build, and here’s why” — is better than silence, and better than a promise we can’t keep.
What we don’t do
Build the most-requested feature immediately. The most-requested feature is almost always a sign of what users are most aware of needing, not what would most improve the product. The deeper improvements usually come from the second or third email, the one that says this works but feels wrong because…
Those emails are harder to act on, because they rarely come with a solution attached. Someone tells us a screen feels cluttered, or that they stopped using a feature without quite knowing why. Taken alone, each one is vague. Several together, pointing at the same corner of an app, are often the most valuable thing in the folder.
We also don’t treat requests for new apps as a to-do list. An idea for a whole new product gets the same quarterly look as everything else, and most of them stay ideas. The ones that move forward fit how we work: a focused tool, useful on its own, that we’d want to use ourselves.
What we got wrong
In the first weeks, our instinct was to respond to feedback as it arrived — a quick fix here, a small change there. It felt attentive. It also meant the loudest email of the week set our priorities, and a couple of changes made in a hurry had to be quietly undone. Waiting for the quarterly read is slower, and occasionally frustrating, but it produces better decisions.
A month in, we have a folder of those. We’ll be working through them all summer.