DEV Community: Quentin Dommerc

AI without the hype: using LLMs to reduce noise, not replace thinking

Quentin Dommerc — Sat, 20 Dec 2025 01:17:56 +0000

This is part 4 of my series on AppReviews.
Part 1 is available here
Part 2 is available here
Part 3 is available here

At some point while building AppReviews, I started thinking about AI.

Not in a “this needs AI” way. More in a quiet, slightly reluctant way.

I already had a system that fetched reviews, pushed them to Slack, and made sure feedback was not missed. That alone solved the core problem. But once reviews are always visible, a new issue appears.

There are a lot of them.

Some are useful.

Some are vague.

Some are emotional.

Some are duplicates of the same issue written slightly differently.

Reading every single review works, up to a point. After that, you are back to scanning, skimming, and mentally filtering noise.

That is when I started asking myself a different question:

What if the system helped me understand reviews faster, without pretending to think for me?

What I did not want

Before adding anything AI-related, I was very clear about what I did not want to build.

I did not want:

AI-generated summaries pretending to be insights
magic scores without explanation
a chatbot answering users on my behalf
another dashboard full of charts that look smart but do not help decisions

Most of all, I did not want AI to become the product.

AppReviews exists to shorten the feedback loop between users and product teams.

AI should support that goal, not distract from it.

So the bar was high.

If AI did not reduce cognitive load in a very concrete way, it did not belong.

The actual problem AI helps with

The real problem is not understanding one review.

It is understanding many reviews over time.

When ten users describe the same issue in ten different ways, humans are great at seeing the pattern. But only after reading all ten. That does not scale well when reviews keep coming in.

What I wanted help with was:

grouping similar feedback
spotting recurring topics
getting a rough sense of sentiment trends
surfacing urgency when something suddenly spikes

Not answers. Signals.

Why embeddings first, not prompts everywhere

The first building block I added was embeddings.

Every review can be turned into a vector that captures its meaning. Once you have that, you can compare reviews semantically instead of relying on keywords or star ratings.

That immediately unlocks useful things:

similar reviews can be grouped together
topics emerge naturally instead of being predefined
you can detect “this feels like the same problem again”

For embeddings, I use nomic-embed-text. It is fast, local, and good enough for this use case. Each review becomes a 768-dimension vector stored alongside the raw text.

This step alone already adds value, even without a large language model generating text.

Where LLMs come in, carefully

On top of embeddings, I added a second, optional layer using a large language model.

The model I use is llama3.1:8b, running locally via Ollama. This was an intentional choice.

I wanted:

no per-token cost anxiety
no external API dependency
something that could run on my machine or a small server

The LLM is used for very specific tasks:

estimating sentiment
extracting high-level topics
detecting tone such as angry, neutral, or positive
flagging urgency when relevant

Each review is processed independently.

No long context.

No agents.

No orchestration complexity.

And most importantly:

This entire pipeline is optional.

If the AI processor is disabled or unavailable, AppReviews works exactly the same. Reviews are still fetched, stored, sent to Slack, and visible in the dashboard.

AI is an enhancement, not a dependency.

Async, isolated, and easy to turn off

From an architectural point of view, AI processing is completely decoupled from the core flow.

reviews are saved first
only then are they queued for analysis
processing happens asynchronously, in small batches
failures are retried a few times and then dropped

If Ollama is not running, nothing breaks. There is no user-facing error. The system simply skips analysis.

This was non-negotiable.

AI systems fail in weird ways. None of that should impact the primary job of the product.

Why not “AI-generated insights”

This is probably the question I get the most.

Why not generate summaries like:

“Users are unhappy about onboarding”

or:

“Most complaints are about performance”

The short answer is simple.

I do not trust them.

Those summaries look nice, but they hide uncertainty. They compress nuance into something that feels authoritative, even when it is not.

Instead, AppReviews surfaces raw signals:

these reviews are similar
this topic appears often
sentiment around this feature dropped last week

From there, a human can decide what it means.

AI should help you see where to look, not tell you what to think.

Cost, control, and boring decisions

Running everything locally with Ollama is not the most scalable choice. But it fits the constraints perfectly.

no variable costs
no surprises
no API keys to rotate
no privacy questions about sending user feedback elsewhere

If AppReviews grows, swapping the AI backend is relatively easy. The interface is already isolated.

For now, this setup is predictable and controllable.

That matters more than squeezing out the last percentage of accuracy.

What AI does not do, on purpose

To be very clear, AppReviews does not:

reply to reviews automatically
decide which feedback matters
replace reading reviews
predict user behavior
generate product decisions

AI does not talk to users.

AI does not act on their behalf.

AI does not override human judgment.

It just reduces repetition and helps patterns emerge faster.

The outcome so far

In practice, this approach works surprisingly well.

You still read reviews.

You still reply yourself.

You still make decisions.

But you do it with more context and less noise.

And that is the only promise I am comfortable making.

Start with the human workflow.

Figure out where attention is wasted.

Then see if AI can help reduce that cost.

Not the other way around.

Building AppReviews: the stack, the choices, and the compromises

Quentin Dommerc — Tue, 16 Dec 2025 10:30:53 +0000

This is part 3 of my series on AppReviews.
Part 1 is available here
Part 2 is available here

After talking about why AppReviews exists and how I forced myself to ship a focused v1, it feels natural to talk about the technical side.

Not in a “here’s my shiny stack” way, but as a snapshot of the decisions I made as a solo developer, working nights and weekends, with limited time and a very clear goal: build something reliable, understandable, and good enough to run in production without turning into a second full-time job.

This post isn’t about best practices. It’s about trade-offs.

A boring architecture on purpose

At a high level, AppReviews is a monolith.

It’s a single Next.js 16 application using the App Router. Frontend, API routes, background jobs, and scheduling all live in the same codebase and are deployed together as one unit.

No microservices.
No separate worker processes.
No distributed queues.

Everything runs in one process.

That was a very conscious choice.

The problem AppReviews solves doesn’t require a complex architecture. Reviews are fetched on a schedule, stored, optionally processed, and pushed to Slack. Latency isn’t critical. If a review shows up a few seconds later, nobody cares.

What matters more is reliability and simplicity.

Backend: TypeScript, Next.js, and in-process jobs

The backend is written in TypeScript, running on Node.js 20+, using ESM modules.

I chose Next.js App Router for everything, including APIs. All HTTP endpoints are standard route handlers living under src/app/api. It’s REST-style, straightforward, and easy to reason about.

Background work is handled with node-cron, started inside Next.js instrumentation when the server boots. This is probably the most “controversial” choice, but also one of the most pragmatic.

There’s no Redis.
No BullMQ.
No external queue.

Cron jobs run in-process.

Review fetching runs every 5 minutes in development and every 30 minutes in production. Weekly Slack summaries go out on Monday mornings. Rating checks run at different frequencies depending on the subscription plan. Export cleanup runs hourly.

Is this horizontally scalable? No.

Is it good enough for v1? Absolutely.

If the process crashes, Coolify restarts it and the jobs resume on the next tick. For this use case, that’s acceptable.

Fetching reviews: pragmatic over perfect

For the App Store, there are two paths.

If users want to see appStore reviews, they can configure App Store Connect API credentials and the system will fetch them.

For Google Play, it uses the official Google Play Developer API with service account authentication.

Since it's going to be needed to reply to reviews anyway, why bother with scrappers.

Integrations everywhere, but kept simple

AppReviews integrates with a few external services, but each one is intentionally scoped.

Slack is used to send new reviews, weekly summaries, and rating changes. It uses @slack/web-api. Messages are fire-and-forget. There’s no retry system yet. If Slack is down, the world doesn’t end.

Stripe handles subscriptions, checkout, and webhooks. This is one area where I didn’t try to be clever. Stripe’s patterns are well-documented and battle-tested, so I followed them closely.

Translations are handled via DeepL, optionally.

Transactional emails are sent using Gmail SMTP via Nodemailer. Not SendGrid. Not Postmark. Just something I already had access to and that works.

Analytics are tracked with Umami. Simple, privacy-friendly, and enough to know if people are using the product.

Data layer: Prisma and “good enough” modeling

The database is PostgreSQL in production and SQLite locally. Prisma abstracts the difference, which makes local development painless.

Schema changes are handled through Prisma migrations. There are already quite a few of them, which tells the real story: the model evolved over time.

The data model covers tenants, apps, reviews, replies, embeddings, analysis, rating history, teams, subscriptions, exports, and more.

One evolution I’m happy about is the introduction of an AppData model to deduplicate shared app metadata across tenants. That came later, once it became clear that multiple teams might track the same app.

There’s no Redis. No cache layer. No fancy optimization. Just indexes on the columns that are queried often and trust in Prisma to generate reasonable queries.

So far, it’s been fine.

Frontend: speed first, elegance later

The frontend is also built with Next.js App Router and React.

Most of it is client-side. Server components exist, but I didn’t force myself to use them everywhere just because they’re “the new thing”.

Authentication is handled by NextAuth v5 beta. OAuth providers include Google, Apple, GitHub, and LinkedIn. There’s also a custom email/password flow with bcrypt and email verification. The JWT strategy is mapped directly to the tenant model, which doubles as both user and organization.

Styling is intentionally boring. Plain CSS and inline styles. No Tailwind. No CSS-in-JS. No component library.

The main dashboard page is a single, very large file. Over 2,500 lines. All the state, effects, and UI live together.

Is that ideal? No.

Is it fast to work with as a solo dev? Yes.

Forms use React Hook Form and Zod. Charts use ApexCharts, dynamically imported to avoid SSR issues.

This is very much a “get it working, clean it later if needed” frontend.

Deployment and infrastructure: minimal and cheap

The app is built as a Docker image using Next.js standalone output. There’s a multi-stage Dockerfile and a small entrypoint script that runs Prisma migrations before starting the server.

Secrets are managed via environment variables. There’s no dedicated secrets manager.

Logging uses Winston. Analytics use Rybbit, and it's really great. There’s no APM, no Sentry, no Datadog. But I've setup a grafana with Loki. Yep being solo also means having to learn and setup those things.

CI/CD isn’t visible in the repo. Deployments happen automatically on git push via Coolify.

This setup is intentionally boring and cost-conscious. I mean, cost is close to zero.

Constraints, compromises, and being honest about them

This codebase has a lot of “solo developer energy”.

There are no tests.

There’s no message queue.

There’s no horizontal scaling story.

There are big files.

There are shortcuts.

All of that is intentional.

I optimized for shipping something useful, keeping costs very low, and being able to maintain it alone.

Some things will be easy to change later. Others won’t. That’s fine. Perfect architectures don’t ship products. Imperfect ones do.

If AppReviews grows, the first things I’d revisit are the in-process cron jobs and the single-instance assumption. Background work would need a proper queue, Slack delivery would need retries, and monitoring would become more serious. The big dashboard page would also need to be split at some point.

None of this is urgent today. They’re good problems to have, and I’d rather solve them when they’re real.

And most importantly, I understand it.

In the next post, I’ll go deeper into the AI part: why it’s optional, how it’s implemented, and how I’m trying to use it to reduce noise instead of adding more dashboards.

From Feature Creep to Focus: Deciding What AppReviews Would Never Be

Quentin Dommerc — Tue, 16 Dec 2025 10:30:42 +0000

This is part 2 of my series on AppReviews.
Part 1 is available here

If I’m being honest, my first instinct with AppReviews was to keep adding more.

There’s always this temptation when you build something yourself. The ideas start flowing.

“Oh, this would be useful.”

“This would make it even better.”

“What if I also added this?”

And before you realize it, you’re no longer building a product. You’re building a backlog.

I wanted AppReviews to be useful, but I also wanted it to exist. And at some point, those two goals start to conflict.

The constant pull of “just one more feature”

Once the core was working, it became very easy to imagine what AppReviews could become.

A dashboard with charts.
Advanced filters.
More analytics.
More automation.
More more more.

All of these ideas were valid. Some of them are still on my list. The problem wasn’t the ideas themselves. The problem was that if I kept going down that path, I knew I would never ship.

I’ve been there before. Spending weeks polishing details, adding features, tweaking UX, until the initial excitement slowly fades and the project stalls.

I didn’t want that to happen here.

So I forced myself to ask a very uncomfortable question over and over again:

Is this required for v1, or do I just enjoy building it?

More often than not, the honest answer was the second one.

Shipping v1 meant accepting that it wouldn’t be “complete”

At some point, I had to decide what “good enough” meant.

For AppReviews, v1 had to do a few things really well:

Reviews should be fetched automatically.
They should be visible without effort.
They should reach people where they already are.
And reacting to them should be fast.

That’s it.

Everything else was optional.

This was harder than it sounds, because as an engineer, it’s very tempting to keep improving things. To add safety nets. To add flexibility. To think ahead for every possible use case.

But I kept coming back to the same thought: if v1 already solves the core problem, delaying the release doesn’t actually help users. It only satisfies my urge to keep building.

So I shipped.

Not because there was nothing left to do, but because there was already enough value there.

What AppReviews would not be (at least for v1)

One of the most useful exercises for me was to explicitly define what AppReviews was not trying to become.

It wasn’t going to be a full review management platform.
It wasn’t going to replace support tools.
It wasn’t going to be a heavy analytics product.
It wasn’t going to require hours of setup.

There are already great tools that do those things. I wasn’t trying to compete with them.

AppReviews is intentionally narrow in scope. Its job is to reduce friction and shorten the feedback loop between users and product teams.

Anything that didn’t serve that goal directly was pushed back.

Some of those ideas will probably come back later. Others might never make it. And that’s fine.

Shipping early changed how I think about the product

Releasing v1 didn’t feel like “I’m done”. It felt more like opening a door.

Once the product is out there, feedback becomes real. You stop guessing. You stop building in a vacuum. You start hearing what people actually care about.

That’s a much better foundation for deciding what to build next than a long list of assumptions.

Looking back, I’m glad I resisted the urge to keep adding features before launching. AppReviews is far from finished, but it’s already doing the job it was meant to do.

And most importantly, it exists.

Leaving room to grow

I still have a lot of ideas for AppReviews. Probably too many. Some of them will turn into features. Some won’t.

But by shipping early, I made sure the product stays grounded in real usage, not just in my head.

v1 was about focus.
The next versions can be about refinement.

In the next post, I’ll dive into the technical side of AppReviews: the stack, the architecture, and the choices I made to keep things simple and maintainable as a solo developer.

From “I should check the reviews” to a SaaS

Quentin Dommerc — Mon, 15 Dec 2025 10:49:01 +0000

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.