We've all been there, haven't we?
Especially if you're, um, leading a product team or maybe you're an indie
builder or just running a passion project, that feeling of being totally
swamped by feedback, you know, your inbox is overflowing with, can we add
this emails than a Slack message box out?
Hey, quick thought.
And then someone mentions three more ideas in a quick chat.
It really is like trying to drink from a fire hose sometimes.
How do you possibly cut through all that noise?
How do you figure out what to actually build next when ideas are
just flying in from everywhere?
Well, today we're going to dive into something that might
just help tame that chaos.
Our mission here is to really unpack FIDR.
It's an open source future voting tool.
We want to explore how FIDR can take all that scattered input and turn it
into, well, a structured system, something that helps teams build
features users actually want.
And crucially, we want to explain it so that anyone, even if you're totally
new to this, can get a handle on it.
It's really about getting off that treadmill, just reacting and starting
to, you know, focus your energy where it matters most for this deep dive.
We've looked at some great source material stuff directly from FIDR's
own get started guide and their GitHub repository.
So we've got a pretty solid view.
And before we really jump in, we want to give a quick shout out to the
supporter of this deep dive that's safe server, they handle hosting for
software like this and can support you in your digital transformation.
You can find out more over at www.safeserver.de.
Okay, so let's get started.
What exactly is FIDR?
The description says a simple and elegant feature voting tool.
What does that actually mean in practice?
How does it help with that feedback mess we talked about?
Yeah, that's the really interesting part, how it tackles that, uh, that
messy feedback problem head on.
Instead of you having to chase down ideas from, you know, emails, Slack,
meeting notes, random chats, FIDR gives you one single place, a central hub
that's organized and importantly searchable for all of that feedback.
It just pulls everything together.
This basically takes the guesswork out of deciding what features come next.
You're not just hoping you remembered that one comment from last week.
You get a clear picture of what users are actually asking for.
It helps make sure those important suggestions don't just fall through
the cracks and it's not just theory.
Uh, FIDR is genuinely trusted by teams all over the world.
Product managers seem to really like its simplicity, especially
compared to some, uh, more complex tools out there.
The scale is pretty impressive too.
We're talking over 2000 sites actively using it, more than
30,000 ideas submitted and something like 200,000 votes cast.
That shows real world impact.
Okay.
That central hub idea sounds really powerful, but thinking about someone
just starting out, maybe a small team or even one person, how does it actually work?
Is it complicated to use?
The sources mentioned three simple steps.
No, it's actually designed to be very straightforward, very beginner friendly.
That's one of its strengths.
The first step is just set up.
This is where you create your own feedback site.
You can easily pop in your own logo, tweak the colors, change the text, make
it look and feel like part of your brand and getting started.
You've got two main options.
There's fighter cloud, which is probably the easiest way.
It's fully managed by the fighter team.
So they handle updates, hosting all that stuff.
You just sign up and go.
The other option is self hosted.
This one's free open source, but you are responsible for setting it up
and managing it on your own server.
So you pick based on your technical comfort level, really.
Right.
So you choose the path that fits you best.
Okay.
What's next after setup?
Step two is collect.
Once your site is up, you invite people, your users, customers, maybe
internal teams to visit your fighter site.
They can then easily suggest new ideas, request features they'd like to see,
or report bugs or issues they've run into.
It becomes the go-to place for all that input.
Simple enough.
And the third step.
The third step is deliver.
And this is all about closing the loop, keeping everyone informed.
When you as the product team update the status of a suggestion, maybe it moves
to under review or in progress or gets marked as completed, users get notified.
Specifically, anyone who submitted or voted on that idea gets an update.
It keeps things transparent.
Okay.
So that's the keeping everyone in the loop part.
That sounds like it sounds like it tackles a major frustration point.
How does that transparency really help build trust and does it actually save time?
Oh, absolutely.
It's a huge deal on both fronts.
Think about it.
Without something like this, users often feel like their feedback just
disappears into a void, right?
They wonder if anyone even read it.
That erodes trust over time.
But when fighter automatically notifies them about progress, it sends a clear
signal.
We heard you.
We're considering your idea.
Here's what's happening.
That makes users feel valued, respected, like they're actually part of the
product's journey.
It builds community.
I can see that.
And yes, it definitely saves time.
Think about how many, hey, any update on feature X emails or messages teams get
fighter basically automates that communication.
Users can see the status themselves or they get notified.
It frees up the product team from constantly answering those repetitive
questions, letting them focus on, you know, actually building.
It streamlines things a lot.
Okay.
So the basic workflow is set up, collect, deliver pretty clear, but fighter seems
to offer more than just like a tidy feedback list.
What are the bigger problems that help solve?
Right.
It goes deeper.
The sources highlight a few key areas.
First, keeping users engaged fighter isn't just a suggestion box.
People throw ideas into it's interactive users, submit, they vote.
They can even discuss ideas with each other and with the team.
It creates this, uh, community feeling people feel involved, invested, and that
makes them more likely to stick around.
fighter makes this easy too, with things like one click sign in using Google,
GitHub, Facebook, whatever people already use, less friction.
So that makes it easy for them to jump in.
Exactly.
And it supports multiple languages over 10, like Spanish, German, French,
Portuguese.
So your users worldwide can participate comfortably in their own language.
That's crucial for engagement.
What else?
Second big thing, figuring out priorities.
This is huge for any product team.
Instead of guessing or just listening to the loudest person in the room, fighter
lets the users vote.
The ideas with the most votes naturally bubble up to the top.
It's like crowdsourcing your roadmap priorities.
You get actual data showing what features people want most.
This makes decisions much easier and helps focus development effort where we'll
have the biggest impact.
No more just hoping you pick the right thing.
Data driven decisions, basically powered by the users themselves.
Precisely.
And you can organize things further using tags.
You can create public tags everyone sees or private ones just for your team's
internal use, maybe to categorize feedback or track progress helps keep things
manageable.
Got it.
And the third major benefit.
Saving time and effort.
Honestly, managing feedback without a dedicated tool can easily become someone's
full-time job.
It's a lot of work collecting, sorting, tracking, responding.
FIDR is designed to be lightweight and efficient.
It streamlines that whole process.
Because users are submitting and voting directly, they're doing a lot of the
initial organization for you.
It just saves the team a ton of time and mental energy, letting them focus on
higher value work.
It's meant to be easy to set up and easy to maintain.
And there are specific features supporting these benefits, right?
Like customization.
Yeah, lots of neat features.
We mentioned the one-click sign-in and multi-language support.
There's also the ability to fully customize the look with your brand, custom
CSS, logo, et cetera.
You can make it a private site if you only want specific people like internal
teams or beta testers to access it.
For more technical folks, there's a public API for integrations and webhook support.
So you could say automatically post new high-priority ideas to a Slack
channel or Discord.
Ah, okay.
So it can connect to other tools.
Right.
And for writing the actual ideas and comments, it supports markdown styling so
people can format their text nicely.
Okay.
That gives a much clearer picture of the features and benefits.
Now you mentioned earlier, it's open source.
Let's shift gears a bit and talk about that philosophy.
What does that mean for FIDR?
Good question.
Yes, FIDR is 100% open source, specifically under the AGPL 3.0 license.
What that means fundamentally is transparency.
Anyone can look at the code, but it also fosters a community because it's open
source, people can contribute fixes, improvements, translations.
It's a collaborative effort.
The license ensures it stays free to use and modify.
It was started by Giller-Mayoning, now maintained by Matt Roberts.
And there's a whole community of contributors on GitHub helping out.
You can see the activity there, thousands of stars, hundreds of forks.
And kind of a cool point.
They actually use Fyter themselves to gather feedback on Fyter.
Dogfooding, as they say.
It shows they believe in their own product.
That's always a good sign.
Definitely.
Now for people who don't want to deal with hosting it themselves, there's
Fyter Cloud and they have what they call simple no-tricks pricing.
It's currently $30 a month, and that includes basically everything.
All features, unlimited customers, unlimited feedback, unlimited members.
It also covers the multiple languages, using your own domain, the brand
customization, the API access, social logins, even enterprise SSO login, and
the private site option, pretty comprehensive.
And is there a way to try it before committing?
Yep.
They offer a 15 day free trial and you don't need to put in a credit card to
start it so you can easily take it for a spin and see if it fits your workflow.
That sounds very straightforward and user-friendly, tying back to that
simplicity thing, which leads me to ask that open source nature you described.
How do you think that might actually contribute to FIDR being simple and
effective?
Is there a connection there?
Oh, I think there's a strong connection.
Yeah.
Open source projects often have this inherent pressure towards elegance and
clarity in the code because lots of different people might look at it or
contribute that often translates into the user experience too.
There's less incentive to just tack on feature after feature, you know, feature
bloat.
The focus tends to stay on the core problem.
If a feature adds too much complexity without adding significant value, the
community might push back or it just won't get prioritized.
It helps keep the tool lean and focused.
Plus, because the community is using the tool and contributing to it, the
development is often guided by very real practical needs.
It evolves based on direct user feedback, which naturally leads to a more
effective and intuitive product.
It's a nice feedback loop in itself.
That makes a lot of sense.
It's almost like the development process mirrors the tool's purpose.
Well, this has been a really illuminating look at Fader.
It really paints a clear picture of how moving to a more structured,
transparent way of handling feedback isn't just about organization.
It's about building better products by truly listening.
It shifts you from guessing what users want to actually knowing and involving
them in the process, which builds that engagement we talked about.
Absolutely.
And maybe that leaves us with a thought for you, our listener, to ponder.
If a tool like Fader works so well for centralizing feedback and empowering
users and product development, where else could we apply this model?
This idea of transparent data-driven prioritization based on collective input.
Think about community projects maybe, or how nonprofits make decisions, or even
strategy within larger organizations.
What happens when we build systems to truly listen and give people a voice in
the things that affect them?
What stands out to you about building trust through that kind of structured
feedback, something to think about?
A great question to end on.
Thank you so much for joining us on this deep dive into FIDR.
We hope this gives you one much better understanding of the tool and the value
of managing feedback effectively.
And one last thank you to our supporter, Safe Server.
Remember, you can learn more about how they can help with your digital
transformation at www.safeserver.de.