🚀 I shipped on a Friday and turned my side project into a dashboard

Samuel Fialho — Fri, 10 Apr 2026 21:00:35 +0000

“Never merge on a Friday.”

If you’ve been around software long enough, you’ve heard it.
And honestly… it’s good advice.

But today, I just ignored it.

Not recklessly — this is a pet project, after all — but still knowingly. And that merge turned into something bigger than expected: a new version of SubCat, now evolving from a simple CI watcher into a full dashboard experience.

Let me show you what changed 👇

🐱 What is SubCat?

SubCat is a desktop app that helps you monitor your CI pipelines and flaky tests without constantly refreshing GitHub.

It started simple: watch workflows, get notified, stay sane.

But over time, I realized something:
I didn’t just want notifications, I also wanted visibility.

🧭 From watcher to dashboard

The biggest change in v1.1.1 is the introduction of a Dashboard.

Instead of jumping between views, you now land on a central screen that gives you:

Run statistics
Recent activity
Quick actions

It’s a small shift in UX, but a big shift in mindset: SubCat is no longer just reactive, it’s informational.

🧪 Going deeper into PRs

Working with pull requests got a lot more powerful.

I introduced a 3-level drill-down navigation:

My PRs → PR Checks → Workflow Runs

This makes it much easier to go from a high-level overview to the exact failing job without losing context.

On top of that:

You can now see PR review status alongside CI checks
You can rerun only failed jobs instead of the whole workflow
You can even cancel running workflows directly from the app

Less clicking. Less waiting. More control.

📊 Flaky tests, but make it actionable

Flaky tests are one of the main reasons I built SubCat. So I doubled down on that.

You can now generate a Flakiness Report:

Exported as Markdown
Includes pass/fail counts
Lists failed test names per attempt

It’s simple, but incredibly useful for debugging patterns and sharing with your team.

📌 More control, less friction

A few features that made the day-to-day experience smoother:

Pin workflows to the sidebar and track their latest status
Set a repeat count when watching a run
Pending reruns are resumed automatically when reopening the app
New Notification Center with unread badges and history

These are the kinds of features you don’t notice individually, but together they make the app feel much more “alive”.

🐧 Linux support (finally)

This was a big one. SubCat now runs on Linux.

And since not all environments have a keychain available, token storage now falls back to:

~/.config

It’s not glamorous work, but it matters.

🎨 Polishing the experience

This release also includes a bunch of UX improvements:

Sections renamed to My PRs, Runs, and Workflows
Status text humanized (in_progress → Running, etc.)
Cleaner UI (less visual noise on secondary actions)
+ Watch Run simplified to + Watch
New loading animations (yes, there’s a cat 🐱)
Keyboard shortcut (⌘N) to quickly open the watch form

⚠️ About that Friday merge

Everything went well.

But while waiting for CI to pass, I was reminded why the rule exists: a bug on Friday evening is just… different.

Still, this time it worked out.

📦 Try it out

SubCat v1.1.1 is now available for free:

👉 https://subcat.todaywedream.com/

🛠️ What’s next?

This release was about depth and visibility.

The next step? Probably insights.

Because once you can see everything clearly…
you start wanting the system to tell you what matters.

If you’re building tools in public, working with CI daily, or fighting flaky tests, I’d love your feedback.

Tired of babysitting your pipelines?

Samuel Fialho — Mon, 06 Apr 2026 20:02:56 +0000

There’s a specific kind of failure every engineer working with CI knows:

A test fails.
You rerun it.
It passes.
You rerun again.
It fails.

Now you're not debugging anymore, you're dealing with non-deterministic failures. And trying to answer a simple question: is this actually broken, or just flaky?

So you start the loop: you rerun the CI; you open GitHub Actions url; you wait; you check again; when it finishes, you rerun it again; you repeat it. Not because you want to, but because you need signal.

Meanwhile, your attention is split. You can’t fully go back to coding because part of your brain is still waiting for the result. That’s the problem I wanted to solve. So I built SubCat.

What SubCat is

A small macOS app. You paste a GitHub Actions run URL, go back to work, and get a native notification when it finishes. You click it and it opens the run. No tabs. No babysitting.

Repeat mode: turning guesswork into signal

This is the core idea. Instead of manually rerunning a flaky test over and over, SubCat does it for you and gives you a simple report in Markdown format.

It’s not full-blown observability. It’s point-in-time investigation. Tools like BuildPulse or Trunk are great, but they require setup and are built for long-term analysis.

SubCat is intentionally different:

local;
zero setup;
focused on “I need to understand this failure now”

Why this exists

This started as a productivity problem, but it turned out to be a signal vs noise problem in CI. The time cost isn’t the reruns themselves, it’s the constant context switching while waiting for answers. SubCat removes that loop.

Technical notes (for those who care)

Built with Electron (pragmatism > purity)
Native notifications + Keychain via safeStorage
GitHub OAuth Device Flow (no PAT copy/paste)
SQLite (better-sqlite3) with a test-time swap to node:sqlite
Polling extracted into a decoupled PollManager (event-driven, fully testable)
CI/CD with code signing + notarization + auto-update via GitHub Releases

The goal wasn’t to build the “perfect” stack but I wanted to optimize for iteration speed and real-world usefulness.

Why I’m sharing this

SubCat is open source and free, but this is also the kind of project I value most as a developer. It started as a personal project (a problem I hit in my day-to-day work) but I approached it with the same standards I’d expect in a production system:

clear architecture;
explicit tradeoffs;
testable components;
end-to-end ownership (from idea to CI to distribution).

If flaky tests are part of your daily life, this might help: https://subcat.todaywedream.com/

Curious how others deal with flaky tests. Reruns, quarantine, retries in CI, or something else? Let me know. Cheers.

DEV Community: Samuel Fialho