The Birth of Flashlight: Why SaaS Founders Shouldn't Iterate in the Dark

Building a SaaS product without user feedback is like navigating a maze blindfolded. Here's why we built Flashlight, and why listening to your users should be your North Star.

When Side Projects Teach the Most Important Lessons

When I launched Doxy (doxy.ink), a tool for generating personalized PDFs from Google Docs templates, I had a clear vision of what I thought users needed. The product solved a real problem—simplifying the creation of customized documents at scale—and the technology worked as intended.

But something was missing.

I'd built the product I thought users wanted, not necessarily what they actually wanted. As feature requests started coming in, priorities shifted, and user questions revealed gaps in my understanding, I realized I was essentially iterating in the dark.

The Costly Game of Product Guesswork

Every SaaS founder knows the drill:

• You build a feature you think users will love
• You spend weeks perfecting it
• You launch it with excitement
• And then... crickets. Or worse, confused support tickets.

Meanwhile, the simple improvement that would drive real value goes unnoticed on your backlog. This cycle is not just inefficient—it's existentially threatening to early-stage products with limited resources and runway.

As Doxy grew, I found myself constantly questioning: "Am I building what matters most to my users right now?" The answer was often unclear.

The Lightbulb Moment

After one particularly frustrating product meeting where we debated which features to prioritize based on gut feeling rather than data, I realized we needed a systematic approach to collecting, organizing, and prioritizing user feedback.

Thus, Flashlight (flashlight.icu) was born—a dedicated tool to illuminate what users actually want, not what we think they want.

Why "Flashlight"?

The name emerged naturally from our core insight: you can't iterate effectively in the dark. You need a light to illuminate the path forward.

Without systematically collected user feedback, product development becomes a game of expensive guesswork. Flashlight provides that beam of clarity, letting users vote on features and improvements so you know exactly what will drive the most value.

The Three Pillars of Feedback-Driven Development

Building Flashlight helped crystallize what I now consider the fundamental principles of effective SaaS iteration:

1. Collect Systematically, Not Accidentally

Before Flashlight, our feedback lived in scattered Slack messages, support tickets, and hastily scribbled notes from calls. Important signals got lost in the noise.

Systematic collection means creating dedicated channels where feedback is expected, encouraged, and properly captured. This means having a clear place for users to share their thoughts, whether they're reporting bugs, requesting features, or providing general feedback.

2. Prioritize Democratically, Not Autocratically

The loudest customer isn't always representative of your user base. By implementing voting, Flashlight transformed our prioritization from "who shouted loudest recently" to "what would benefit the most users."

This democratic approach ensures you're building for the many, not the few, while still keeping an eye on strategic priorities that might not be immediately obvious to users.

3. Communicate Transparently, Not Silently

Users don't just want to give feedback—they want to know it's being heard. Flashlight's public roadmap feature creates a virtuous cycle:

• Users see their feedback acknowledged
• They understand what's coming next and why
• They remain engaged with the product's evolution
• They contribute more thoughtful feedback

This transparency builds trust and patience, turning users into partners rather than just customers.

Eating Our Own Dog Food

The most validating part of building Flashlight has been using it for its own development. Features we thought were must-haves frequently ranked below simpler improvements in user voting. Without this feedback loop, we would have overbuilt and under-delivered.

Some surprising insights from our own Flashlight implementation:

• Users cared more about integration capabilities than the fancy analytics dashboard we'd planned to prioritize
• A simple JSON export function received more votes than several complex features we'd mapped out
• Small UX improvements collectively gathered more enthusiasm than any single large feature

Each of these insights saved us weeks of development time that would have been spent on lower-impact work.

From Founder to Founder: Lessons Learned

If I could go back and give myself advice when starting Doxy, it would be this: Don't wait to implement a feedback system.

The cost of building the wrong features is far higher than the investment required to collect and prioritize feedback properly. Here's what I recommend:

1. Start collecting feedback from day one, even before your product is fully built
2. Make feedback visible to your entire team, creating shared understanding
3. Close the loop with users by acknowledging their input and showing how it influences your roadmap
4. Quantify the impact of feedback-driven decisions to reinforce their value

The Future of Product Development Is Illuminated

Building Flashlight while growing Doxy has fundamentally changed how I approach product development. I no longer see feedback as just a nice-to-have input but as the essential fuel that powers effective iteration.

In today's competitive SaaS landscape, the winners won't be those who build the most features or have the cleverest marketing—they'll be the ones who most effectively translate user needs into product improvements.

Don't iterate in the dark. Shine a light on what your users truly need, and let that guide your path forward.

---

Interested in trying Flashlight for your own product? Visit flashlight.icu to see how it can transform your feedback collection and prioritization process.