From “I should check the reviews” to a SaaS

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

For a long time, app reviews lived in a weird place for me.

I knew they mattered. I knew they were important. I’ve been building Android apps for more than ten years, and I care a lot about product quality and user experience. Reviews are one of the rare places where users tell you, very directly, what they think.

And 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. Which usually meant opening App Store Connect, then Google Play Console, logging in, clicking around, scrolling, trying to get a sense of what happened since the last time.

Most of the time, it felt like a chore.

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. We didn’t want dashboards, charts, or weekly reports.

We just wanted to know when a new review came in.

Ideally, it should show up in Slack. Same place as deploy notifications, CI messages, and alerts. Somewhere we already look all day. Or a different channel.

When we started looking at existing tools, it felt like 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 really make sense.

So the alternative was manual checking.

And that’s where things start to break down.

Doing it manually is annoying, but worse than that, it’s easy to forget. You tell yourself “I’ll check later”. Later becomes tomorrow. Tomorrow becomes next week. Suddenly, you’re reading a review from seven days ago.

By then, the moment is gone.

That part bothered me more than I expected.

A user who leaves a bad review is often still engaged. They’re annoyed, but they cared enough to write something. If you reply quickly, you can clarify, ask questions, explain, sometimes even fix the issue before it turns into something bigger.

Replying days later doesn’t have the same effect. It feels distant. Sometimes pointless.

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

After seeing this pattern repeat a few times, 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 just fetched reviews and posted a message in Slack when something new appeared.

That was it.

And yet, the impact was immediate.

Reviews stopped being something you had to remember to check. They just showed up. Someone would notice a message in Slack and say “Oh, I saw that one” or “That explains the support ticket we got yesterday”.

Sometimes it would start a conversation. Sometimes it would lead to a quick reply. Sometimes it would just sit there, but at least it was visible.

It felt… healthier.

What surprised me was how small the change was, compared to the effect it had. We didn’t analyze anything. We didn’t optimize. We just removed friction.

That’s when I realized the core problem wasn’t access to reviews. Anyone can access them. The problem is that they live in places you have to actively go to, and anything that requires a recurring manual action will eventually be 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. Sometimes I’d discover feedback way too late and think “I wish I had seen this earlier”.

Same pattern. Different context.

That’s when the idea of turning that 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. Something that doesn’t try to do everything, but does one thing well: make 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.

So the focus stayed very narrow: visibility, timeliness, and context.

Everything else was secondary.

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 don’t “check reviews” anymore. You react to them.

That shift is small, but it matters.

At some point, this side project started to take more shape. Nights, weekends, small iterations. A lot of decisions about what not to build. 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.

That moment where you think: “I should check the reviews.”

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.