How We Made PR Reviews Work for Quality and Speed

Buggato — Mon, 11 Aug 2025 09:39:52 +0000

In any web project, there comes a point when changes need to hit production, whether it’s a new feature, a bug fix, or a maintenance tweak.
Writing code that works is one thing. Writing code that’s clear, maintainable, and aligned with team standards is another.

That’s where Pull Request Reviews come in. Done well, they boost product quality and help the team grow.

What a PR Review is

A PR Review isn’t just about pointing out mistakes. It’s a chance to:

Show the changes you’ve made
Explain why you made them
Get feedback against shared quality standards

It serves two purposes:

Increase code quality before deployment
Share knowledge across the team

How We Made PR Reviews Work for Us

Over time, we’ve shaped a process that keeps quality high without killing development speed.

1️⃣ Slicing: Smaller PRs, Faster Reviews

We used to have PRs touching 60+ files, painful to review and easy to delay.

Now we slice features into small, releasable parts.
If the full feature has a fixed release date, we still ship slices behind a Feature Flag, hidden in production until we flip the switch.
This way, we practice continuous delivery with frequent, low-risk deploys.

Clear scope is key, so we involve PMs and POs early. On average, we keep PRs under 25–30 files. The smaller, the better.

Pro tip: We use GitHub Draft PRs as an early check; if a change is unnecessary, it gets reverted before review.

2️⃣ Sync vs Async Reviews

Not all PRs are created equal:

Sync: Live meeting + quick visual demo. Ideal for big changes or new features.
Async: Review anytime, no meeting needed. Ideal for bug fixes and small refactors.

3️⃣ Automating with Slack

A simple script sends PR review lists to Slack.
For Sync reviews, it also includes:

The assigned (random) reviewer
The meeting link

We set two Sync days a week to keep things predictable.

4️⃣ How Sync Reviews Happen

The whole team joins
The developer walks through changes while the reviewer checks the PR
Feedback is added as comments
The merge is blocked until two members approve

It’s a built-in quality gate and prevents risky shortcuts.

Final Thoughts

Yes, PR reviews slow things down, especially in a startup where speed feels critical. However, once a project matures, they’re no longer a bottleneck.
They’re an investment: fewer bugs, higher quality, better knowledge sharing.

Today, we wouldn’t ship without them.

How do PR Reviews work for you? Let's discuss it 👇!

I have created Fullstacco; now what?

Buggato — Thu, 01 Sep 2022 06:29:56 +0000

This summer, I developed this MERN boilerplate, which, for those who don't know what MERN stands for, is an acronym for MongoDB, Express.js, React.js and Node.js.

Before, I searched for a basic full-stack boilerplate for studying the Back-End dark side and possibly updating with dependencies. However, on Github, I have found only old repositories, which are outdated.

I started developing one solution with the basic functionalities I was searching for, and in the meantime, I am practising with Node.js and Express.js.

So here we go, Fullstacco (pronounced /fullstakkɒ/) is an open-source platform with:

Classic Login
Classic Signup
Reset password
List of users
Delete, update and creation of user
Roles per user (Admin|Account)

I think those are the minimum features a MERN app should have; the Front-End and Back-End folders are separated to be more scalable for extensive applications.

I am eager to receive feedback from the community to improve this project; I will try my best to keep it updated.

Enjoy

DEV Community: Buggato