From “I should check the reviews” to a SaaS

Source: Dev.to

Introduction

This is the first part of my journey to creating my SaaS AppReviews.

The Problem

For a long time, app reviews lived in a weird place for me. I knew they mattered and were important. After more than ten years of building Android apps, I care a lot about product quality and user experience, and reviews are one of the rare places where users tell you, very directly, what they think.

Yet they were never really part of my day‑to‑day work. At work, reviews were something you checked “from time to time”, or when something went wrong, or when someone remembered. That usually meant opening App Store Connect or Google Play Console, logging in, clicking around, scrolling, and trying to get a sense of what happened since the last time. Most of the time, it felt like a chore.

The Trigger

The real trigger for AppReviews came from a very practical need at work: we wanted to put some basic checks in place around user reviews. Nothing fancy—no dashboards, charts, or weekly reports. We just wanted to know when a new review came in, ideally showing up in Slack alongside deploy notifications, CI messages, and alerts.

When we looked at existing tools, everything was either too much or too expensive. Some solutions are clearly built for large companies with dedicated teams handling reviews and customer feedback. They’re powerful, but also overkill if all you want is a simple signal. For what we needed, the cost and complexity didn’t make sense, so the alternative was manual checking.

Manual Checking Breaks Down

Doing it manually is annoying, but worse than that, it’s easy to forget. “I’ll check later” quickly becomes tomorrow, then next week, and suddenly you’re reading a review from seven days ago. By then, the moment is gone.

A user who leaves a bad review is often still engaged. If you reply quickly, you can clarify, ask questions, explain, or even fix the issue before it turns into something bigger. Replying days later doesn’t have the same effect—it feels distant and sometimes pointless.

Missed replies aren’t just about ratings; they’re missed chances to understand what actually happened, missed context, and missed feedback that could have helped avoid the same issue for the next user.

The First Hack

After seeing this pattern repeat, I did what I usually do when something annoys me enough: I hacked together a script. The first version was ugly—no UI, no configuration screen. It simply fetched reviews and posted a message in Slack when something new appeared.

The impact was immediate. Reviews stopped being something you had to remember to check; they just showed up. Someone would notice a Slack message and say “Oh, I saw that one” or “That explains the support ticket we got yesterday”. Sometimes it started a conversation, sometimes it led to a quick reply, and sometimes it just sat there—but at least it was visible. It felt… healthier.

Realizing the Core Issue

What surprised me was how small the change was compared to the effect it had. We didn’t analyze anything or optimize; we just removed friction. The core problem wasn’t access to reviews—anyone can access them. The problem was that they lived in places you had to actively go to, and any recurring manual action eventually gets delayed.

Around the same time, I noticed I was doing the exact same thing on my own projects. I’d ship something, feel good about it, then think “I should check the reviews”. Sometimes I would, sometimes I wouldn’t, and sometimes I discovered feedback way too late and thought “I wish I had seen this earlier”. Same pattern, different context.

Turning the Script into a Product

That’s when the idea of turning the script into something more serious started to feel obvious. At first, I didn’t think of it as a product; it was more like “this should exist”. Something simple, affordable, and focused—doing one thing well: making sure reviews reach you without effort.

Once I started building it properly, new questions came up:

• If you centralize reviews, how do you avoid creating another place people stop checking?
• If you have dozens of reviews, how do you quickly understand what’s going on without reading everything?

I’ve always been more interested in reducing noise than adding features. Most tools fail not because they don’t do enough, but because they do too much. I didn’t want AppReviews to become another dashboard people open once and forget.

Design Principles

The focus stayed very narrow:

• Visibility – reviews appear where you already look.
• Timeliness – you see them as soon as they’re posted.
• Context – enough information to act without digging through a console.

Everything else was secondary.

Changing the Relationship with Reviews

What I found interesting is that once reviews are always visible, your relationship with them changes. They stop being something slightly stressful you avoid and become part of the feedback loop of the product. You no longer “check reviews”; you react to them. That shift is small, but it matters.

Building the Side Project

At some point, this side project started to take more shape: nights, weekends, small iterations, many decisions about what not to build, and a lot of resisting the temptation to add features just because I could. I wasn’t trying to build the ultimate review platform; I was trying to fix a very specific, very human problem I kept running into—the moment when you think, “I should check the reviews.”

Next Steps

In the next post, I’ll talk about how I decided what AppReviews should focus on, and why cutting features turned out to be one of the most important parts of the project.