Whistlr Feature Requests: What Actually Happens After You Share an Idea

When you send one of your Whistlr feature requests to ETAPX, it doesn't go into a suggestion box nobody opens. It joins feedback from Campus on Discord, Circuits and SubCircuits, app store reviews and support conversations. The team looks for the need underneath it, tests promising directions with early testers in Campus, ships the strongest version, keeps refining after launch, and then explains publicly what happened, including when the answer is "not right now." That last step is the one we're investing in most, and it's a big part of how we're changing the way the whole community builds Whistlr with us.

This guide walks through that path in practical terms. You'll find where to send an idea and which channel fits which kind of request, what the team does with it once it arrives, which features you can already use because someone asked, and a simple way to write a request that's easy to act on. We'll also be candid about the limits, because a feedback process that overpromises is worse than one that doesn't exist.

Where can you send Whistlr feature requests?

Feedback reaches the team through a lot of doors, and none of it arrives neatly organized. That's fine. What helps is knowing which door suits what you're trying to say.

What happens to a Whistlr feature request after you send it

The process is more deliberate than "most upvotes wins." Here is the path an idea follows, step by step.

1. It's collected alongside everything else. Your request joins feedback from every channel above. A single message matters, and so does the pattern it might be part of.
2. The team looks for the need behind it. The question isn't only "what did they ask for?" but "why are they asking?" More on this below, because it's the step that most changes outcomes.
3. Promising directions get tested early. Rough versions go to the beta and early access channel in Campus, where people who use the app every day can poke at them and give fast, blunt feedback.
4. It ships, and listening continues. Real usage at full scale reveals things testing never does, so the team keeps refining after launch.
5. The outcome gets explained. Whether an idea ships, gets reshaped or gets set aside, we explain what happened and why through PX News, the ETAPX YouTube channel and Campus.

Not every idea goes through every step. Some get set aside partway through. But the path is visible, and you should always be able to see roughly where an idea sits in it.

Why the team builds for the need, not the literal ask

There's a difference between hearing feedback and listening to it. Hearing is collecting requests in a spreadsheet. Listening is understanding why people are asking. That distinction drives most of what happens in step two.

Say someone asks for a very specific toggle to turn off one type of notification. Taken literally, that's a small settings change. But if a lot of people are asking for toggles like it, the real message may be that notifications feel noisy overall. Building one toggle would answer the request and miss the problem. Rethinking how noisy notifications are would answer the problem, and probably make that toggle unnecessary.

Another example. "Add a drafts button here" is a solution. "I can't find my drafts quickly when I'm about to post a Mini" is a problem. The second version gives the team room to find the best fix, which might be a button, or might be something better that nobody thought to suggest. This is also why none of the community-requested features you'll read about below shipped exactly as first proposed.

The proposed fix is a clue. The frustration underneath it is the actual brief. When we get that part right, the person who asked can usually tell we understood them, even if what shipped looks different from what they pitched.

— The Whistlr product team

Whistlr features that started as community requests

The best argument for building this way isn't a philosophy. It's the list of things you can already use on Whistlr because someone asked.

Each started as a request, a complaint or a pattern the team noticed in how people used the app. Each shipped in the form that best met the underlying need. Relationship status is a good example of the community shaping not just whether something got built but how: the insistence on it being mutual, consent-based and audience-controlled came from the people asking for it.

What's changing in how ETAPX handles feature requests

Most of what's above has been happening informally for a while. As the community gets bigger and more varied, including people in regions Whistlr has recently expanded to, informal isn't enough. The platform is also much deeper than it used to be, with Circuits and SubCircuits, Waves, Minis, WTC Gems, Creator Studio, Flow, Storefronts, Live Shopping, Halo, Profile Skins and relationship status each serving different people. The more a platform does, the more its users know about it that the builders don't. So we're building real infrastructure around the loop.

• Visible decision-making. The PX team is preparing daily build-in-public streams, coming soon, so you'll be able to watch design reviews and product discussions as they happen and weigh in before decisions are final.
• Clearer "you said, we did" updates. We want to connect shipped changes to the feedback that inspired them, so you can trace your input through to the result.
• Honest "not right now" answers. Silence is the worst possible response to an idea. We're committing to explaining more often when something isn't being built, and why.
• Broader early access. The beta and early access channels in Campus will keep growing as the place to test upcoming features with real people.
• Quieter voices weighed on purpose. Newer creators, smaller Circuits and people in newer regions get deliberate weight, not drowned out by whoever posts the most.
• Earners shape earning tools. Changes to Creator Studio, Flow, Storefronts, Live Shopping and other monetization tools will increasingly be shaped with the creators and business users who depend on them.

The reasoning behind that last item is simple. Monetization, streaming and commerce decisions directly affect how creators and business users pay their bills. Those aren't decisions to make in a vacuum, and the old cycle of build internally, ship, measure the reaction and adjust is too slow when someone's income is on the line. We'd much rather hear we're wrong on day one, from a creator telling us in real time, than discover it months later as a slow drift away from a feature.

A Whistlr feature request from start to finish: a worked example

Here's how one idea might travel through the more collaborative process. It's an illustration of the path, not an announcement of a specific feature.

The pattern

A creator in Campus mentions that planning a Storefront drop around a Flow stream takes too many steps. A few other sellers reply that they've felt the same thing. Nobody proposes a finished solution, and that's fine. What the team hears is a pattern: people who sell while they stream are juggling too much at once.

The conversation

Someone on the product side follows up directly and asks how those creators prepare for a live sale today. The answers show the real problem isn't one missing button. Preparation and the live moment feel disconnected. That insight becomes the brief.

The test

Designers sketch a few directions and, once daily streams are running, may walk through them live with the creators who raised the issue. The strongest direction gets built, and an early version goes to the beta and early access channel. Testers find the rough edges: a step that's still confusing, a setting that's buried, a flow that breaks on a smaller phone.

The explanation

When the improvement ships to everyone, the story gets told publicly in PX News, possibly a YouTube walkthrough, and in Campus, with credit to the feedback that started it. Then the team keeps listening, because full-scale use always turns up something new.

How to write a Whistlr feature request the team can act on

You don't need product jargon to give great feedback. You need a few pieces of information that make your experience easy to understand and reproduce. Here's a simple template you can copy into Campus.

1. What I was trying to do: the goal, in one sentence.
2. What got in the way: the moment it went wrong or felt slow.
3. How often it happens: once, sometimes, every time I stream.
4. My setup: the device I'm on and which part of the app I was using.
5. Why it matters to me: what it costs you, whether that's time, sales, or just patience at 11pm.
6. Optional: an idea for a fix, clearly labeled as one idea rather than the only answer.

A few habits make your feedback even more useful. Be candid and kind: blunt is welcome, as long as you assume everyone involved wants Whistlr to be great. Join early access if you enjoy testing unfinished things. And follow up after something changes to tell us whether it actually solved your problem. That second round of input is often the most valuable of all, because it tells us whether we understood the need or just the words.

Whose feature requests count? Everyone's

Building together isn't reserved for power users or big creators. Different kinds of people see different things, and the platform needs all of them.

• Everyday users notice the small frictions that decide whether an app feels good to open every day. That perspective drives a lot of the polish work that makes the biggest difference.
• Creators live inside Minis, Creator Studio, Flow and WTC Gems, and know their strengths and gaps better than anyone. Their input on collaborative features like co-streams and duets directly shapes what comes next.
• Community leaders who run SubCircuits carry real responsibility. Their experience with rules, membership, moderation and discussion quality shapes how communities on Whistlr evolve, including the long-term idea of handing more ownership to the people who showed up.
• Business users running Storefronts and Live Shopping keep the commerce tools grounded in how selling actually works.
• People using GLSRM, Ocsidian, Influxx and in.between are part of this too, with each product's community shaping it in ways that fit that product.

When the answer to a feature request is no

Being honest about the limits is part of making this work. Building together does not mean every decision becomes a vote. Choices about safety, privacy and security have to be made on principle, even when they're unpopular. Keeping Whistlr safe and enjoyable, protecting private spaces and maintaining security at scale are responsibilities ETAPX can't hand off to a poll.

It also doesn't mean shipping everything anyone asks for. A product that does that turns into a pile of one-off accommodations instead of a coherent experience. Part of doing this well is having the discipline to say no and the respect to explain why. And it doesn't mean timelines on demand. We can't promise when an idea will ship the moment it's suggested. What we can promise is that ideas are genuinely considered, decisions are explained, and the history of the platform keeps showing that community input matters.

Community-driven doesn't mean decision-free. Some calls, especially on safety, stay with us. What changes is that you see them coming and hear the reasoning, instead of waking up to a change nobody discussed.

— The ETAPX team

The longer-term goal behind all of this is a Whistlr that feels owned by its community rather than merely hosted for it. That idea already runs through how we think about Circuits. Applying it to the product itself is the next step, and a growing PX Campus team, daily streams, Campus on Discord and PX News together form the loop that carries your idea to a decision and back to you.

Frequently asked questions

How do I submit a Whistlr feature request?

The most direct route is Campus, ETAPX's official Discord server at discord.gg/etapx, which has dedicated feedback channels plus a beta and early access channel. You can also share ideas in Circuits and SubCircuits, in comments on ETAPX posts, through app store reviews and in support conversations. Account-specific problems are best handled through support rather than a public channel.

Does every Whistlr feature request get built?

No. The team looks for the underlying need behind each request and builds for that need, which often leads to a different or better solution than the one proposed. Some ideas won't fit the platform at all. ETAPX is committing to explaining those decisions more often, because leaving an idea unanswered is worse than an honest "not right now."

Which Whistlr features came from user feedback?

Several major features trace back to community requests, including the profile redesign, Halo, relationship status, Echos and Reactions, Creator Studio's standalone home at whistlr.studio and the floating bottom nav. None of them shipped exactly as first suggested. Each was shaped around the need people described, such as relationship status being mutual, consent-based and audience-controlled.

Can I test new Whistlr features before they launch?

Yes. ETAPX shares early builds and recruits testers through the beta and early access channel inside Campus on Discord. Early testers try unfinished versions, report rough edges like confusing steps or layouts that break on smaller phones, and have an outsized influence on how features turn out. That channel is expected to keep growing.

What makes a Whistlr feature request useful?

Describe the problem rather than only the fix, and add context: what you were trying to do, what got in the way, how often it happens, your device and why it matters to you. Then follow up after a change ships to say whether it solved your problem. A clear, specific post does more than the same request repeated across channels.

Are some Whistlr decisions not open to community input?

Yes. Decisions about safety, privacy and security are made on principle to protect everyone on the platform, even when they aren't the popular choice. ETAPX still aims to explain those calls openly rather than make them silently, so the community understands the reasoning instead of being surprised by a change it never saw coming.