Today's Deep-Dive: Fider

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.

transformation at www.safeserver.de.

transformation at www.safeserver.de.