DEV Community: Silas C

I stopped checking five dashboards before writing any code

Silas C — Thu, 16 Apr 2026 06:11:32 +0000

I used to begin every coding session with the same routine: open Claude usage, Codex usage, OpenRouter credits, then check whether my local API and Redis were still alive.

Each check was tiny. Together they were a constant context-switch tax. And when something crashed overnight, I usually discovered it in the middle of real work, not at the start.

So I rebuilt the routine around one rule: I should be able to confirm everything in under two seconds.

That turned into a small menu bar app.

The problem was not missing data

I already had the data. It was just scattered across tabs, terminal commands, and provider dashboards.

lsof/ps for local process checks
web dashboards for quota checks
memory for everything in between

The friction came from stitching those checks together every day.

What changed in practice

Now I open one menu, glance once, and start coding.

Pulse shows:

local service state (up/down)
quota state for Claude Code, Codex, and OpenRouter
reset countdowns so surprises are less likely

It does not try to be a full observability stack. It just answers the first question quickly: am I clear to work?

Architecture notes

A few implementation choices mattered:

Native SwiftUI app, no Electron

Startup is instant and memory stays low (typically around 15-25MB).
Simple health model for services

Service checks stay lightweight. The goal is signal, not deep metrics.
Quota polling on a fixed interval

Enough frequency to stay useful, not so frequent that it becomes noisy.
Config-first setup

Define services/providers once, then reload quickly as the dev stack changes.

A real week with it

Last week, one worker process died after sleep/wake. I saw it in the menu before running tests, restarted it, and moved on.

I also noticed quota dropping faster than expected during a refactor day and changed how I used prompts before hitting a hard limit.

Neither event is dramatic. That is the point. Small failures stopped turning into bigger interruptions.

Why this matters for dev flow

Productivity discussions often jump straight to big tooling changes. But a lot of wasted time comes from tiny repeated checks.

Five checks, several times a day, adds up. Removing that loop has been more useful than I expected.

If your mornings start with tab-hopping and terminal sanity checks, try collapsing them into one glance. Even if you build your own script or menu utility, the workflow change is worth it.

Repo: https://github.com/silas-maven/pulse

I replaced my job search spreadsheet with a simpler CV workflow

Silas C — Fri, 10 Apr 2026 23:48:00 +0000

I replaced my job search spreadsheet with a simpler CV workflow

My spreadsheet worked, until it didn't.

At the start of my job search, I had one Google Sheet with all the right columns: company, role, date applied, status, notes. It looked organised. I felt organised.

Then the volume went up.

More applications meant more CV variants. Backend role? One version. Product-heavy role? Another version. Client-facing role? Different emphasis again. After a few weeks, my spreadsheet had data, but it wasn't trustworthy data.

I started making mistakes:

sending the wrong CV version
forgetting where I'd already applied
updating the sheet days later from memory
scrambling when a recruiter replied and asked questions tied to a version I couldn't find

That was the moment I realised the problem wasn't effort. It was workflow design.

Where the old process broke

The biggest issue was context switching.

I wrote CVs in one place, tracked applications in another, kept notes in a third, and exported files with random names. Every apply session became a mini detective story.

Spreadsheets are great when the object you're tracking is stable. My CVs weren't stable. They changed constantly. So the tracker and the documents drifted apart.

And once trust in your own system drops, everything slows down.

The rule I switched to

I stopped trying to track everything and focused on the minimum that prevents errors.

Here's the system I now use:

One master CV
This is the source file. No sending this version directly.
Three role profiles
I keep specific variants for role families I actually apply to. Not ten variants. Three.
Every export gets a deterministic name
Role_Company_Date.pdf
Track only decision-critical fields
- company
- role
- date applied
- CV version sent
- next action date

That's it.

No giant dashboard. No 25 columns. No illusion of perfect analytics. Just enough structure to avoid avoidable mistakes.

Why this helped more than 'working harder'

Before, I'd spend energy remembering.

Now, I spend energy applying better.

That's the shift.

When a recruiter replies, I know exactly what they saw. When I follow up, I know when and why. When I tailor another application, I start from the right base version immediately.

The process feels calmer because I removed hidden decisions.

A note on tools

I tried a few popular CV tools during this period. Some were polished, but a lot of the friction moved to the end: export limits, paywalls at download, or awkward multi-version handling.

I wanted something that stayed simple for this exact workflow, so I built my own local-first setup around these rules.

The tool matters less than the system, though. If you already have a stack you like, keep it. Just make sure version tracking is a first-class part of it, not an afterthought.

If you're in the messy middle of job searching

Try this for one week:

Reduce your CV variants to the smallest useful set
Name exports consistently
Log version-sent and next-action every single time

You'll feel the difference quickly.

The job market is hard enough. Your process should remove stress, not create it.

Why I built a 15MB SwiftUI menu bar app instead of reaching for Electron

Silas C — Thu, 09 Apr 2026 23:47:59 +0000

Every developer dashboard I've used is either a browser tab I forget about or an Electron app that eats 200MB of RAM to show me three numbers.

I wanted something different. Something that sits quietly in the menu bar, shows me what I need, and gets out of the way. So I built Pulse.

The Problem

My daily workflow involves juggling multiple AI coding tools — Claude Code, Codex, OpenRouter — each with their own usage dashboard in a separate browser tab. On top of that, I run several local services (Postgres, Redis, a couple of dev servers) that occasionally die without telling anyone.

The checking ritual looked like this every morning:

Open Claude Code dashboard — check remaining quota
Open Codex usage page — check remaining quota
Open OpenRouter balance — check remaining credits
Run ps aux | grep postgres — is it alive?
Hit localhost:6379 — is Redis responding?

Five context switches before I've written a single line of code. And if something died overnight, I'd only find out when a build failed or an API call timed out.

Why Not Electron?

The obvious path would have been Electron. Faster to ship, cross-platform out of the box, massive ecosystem. I've built Electron apps before and the DX is genuinely good.

But this app lives in the menu bar. It runs all day, every day. For something with that kind of residency, the numbers matter:

	Electron	SwiftUI (Pulse)
Binary size	~150-200MB	15MB
Idle RAM	~80-120MB	~12MB
Startup time	2-4 seconds	< 1 second
Native notifications	Via bridge	Native
Dark mode	CSS hacks	Automatic
Menu bar integration	Limited	First-class

For a full application with complex UI, Electron makes sense. For a status glance that should feel like part of the OS, native wins.

What Pulse Actually Does

Click the menu bar icon and you see two things:

Service status — green/red indicators for each local service Pulse monitors. If Postgres went down at 3am, you see it immediately when you open your laptop. No more discovering dead services through cascading errors.

AI quota — current usage across Claude Code, Codex, and OpenRouter in one view. When you're burning through tokens faster than usual, you catch it early instead of hitting a rate limit mid-session.

That's it. No charts, no historical data, no analytics dashboard. Just the current state of things you need running.

The Tradeoffs

Honesty time:

Mac-only. No cross-platform story. If you're on Linux or Windows, this doesn't help you. For a menu bar utility, I think that's the right call — menu bar apps are a Mac pattern.
SwiftUI is still maturing. Some things that would take 5 minutes in React took an hour of fighting with SwiftUI's layout system. The ecosystem is smaller and Stack Overflow has fewer answers.
No web technologies. Can't just npm install a charting library. Everything is built with native frameworks, which means more upfront work for each new feature.
Polling, not pushing. Pulse checks service status on an interval rather than receiving push notifications. Good enough for the use case, but not real-time.

Would I make the same choice again? Yes. The result feels right — fast, small, quiet. The kind of utility that disappears into your workflow.

What I Learned

Building a small native app after years of web development was humbling. Things I took for granted (hot reload, flexbox, npm) weren't there. But the constraints forced better decisions:

Fewer dependencies meant fewer things to break
Native APIs meant less glue code
Small binary meant fast iteration on the actual product

If you're considering building a small Mac utility, SwiftUI is worth the learning curve. The menu bar API is straightforward, the app lifecycle is simple, and the result feels like it belongs on the platform.

Repo: github.com/silas-maven/pulse

I Replaced My Job Application Spreadsheet With a Privacy-First Tracker

Silas C — Thu, 09 Apr 2026 22:51:26 +0000

I Replaced My Job Application Spreadsheet With a Privacy-First Tracker

Like most job seekers, I started with a Google Sheet. Columns for company, role, date applied, status, notes. It worked for the first 10 applications.

By application 30, the spreadsheet was chaos. Outdated statuses, missing links, duplicate entries. I'd open it, feel overwhelmed, and close it without updating anything.

The Problem With Existing Tools

I tried Huntr, Teal, and a few others. They all had the same issue: they wanted my CV uploaded to their servers, parsed by their AI, stored in their databases. As someone who builds software, I know what happens to that data.

What I Built Instead

Dossier takes a different approach:

Local-first storage — your data stays on your device
PII sanitisation — before any AI processing, personal details are stripped
Smart matching — AI-powered job-CV matching without exposing your identity
Simple tracking — applied, interviewing, offered, rejected. That's it.

The Technical Bits

The PII sanitisation layer uses named entity recognition to identify and mask personal information before it reaches the matching engine. Your name, address, phone number never leave your device.

The matching itself runs against the sanitised version of your CV, comparing skills, experience patterns, and role requirements.

Early Results

I've been using it for my own job search for 2 weeks. The biggest win isn't the AI matching — it's just having a clean, simple view of where I stand. No spreadsheet anxiety.

Would love feedback from other developers who are job hunting. What would you want from a tool like this?

Dossier is open source and free. Check it out on GitHub

I replaced five browser tabs with a menu bar icon

Silas C — Fri, 27 Mar 2026 05:47:36 +0000

I used to start every coding session by opening the same five browser tabs. Claude Code usage. Codex quota. OpenRouter balance. A quick check on Postgres. A localhost ping to Redis.

None of these checks took long individually. But stacked together, they were a daily friction tax — five context switches before writing any actual code. Worse, if something had died overnight, I wouldn't know until a build failed or an API call returned a cryptic error.

So I moved all of it into the macOS menu bar.

Before and After

Before: Five tabs, five logins, five dashboards. Each one designed for power users who want graphs and historical data. I just wanted to know: is it running, and how much quota do I have left?

After: One menu bar icon. Click it. Green dots mean services are up. Numbers show remaining quota. Close it. Start coding.

The entire interaction takes about two seconds.

What Gets Monitored

Pulse watches two categories:

Local Services

Anything running on your machine that you depend on during development. The default setup covers common suspects:

Database servers (Postgres, MySQL, Redis)
Dev servers and build tools
Background workers and queue processors

Each service shows a simple up/down status. No metrics, no dashboards. If Postgres crashed at 3am while your laptop was asleep, the red dot is there when you open the lid.

AI Coding Quota

If you use AI coding tools, you've probably been bitten by hitting a rate limit at the worst possible moment. Pulse shows current usage for:

Claude Code (Anthropic)
Codex (OpenAI)
OpenRouter

When you're burning through tokens faster than usual — maybe a long refactoring session or a complex debugging chain — you see it trending before you hit the wall.

Why a Menu Bar App?

I tried other approaches first:

Browser extension — worked, but added to the tab noise I was trying to reduce. Also couldn't monitor local services without a companion process.

Terminal dashboard — btop and friends are great, but they take a terminal pane. For something I glance at 20 times a day, that's too much real estate.

Notification-based — alerts when something goes wrong. But I didn't want alerts. I wanted ambient awareness. There's a difference between "tell me when it breaks" and "let me see the current state whenever I want."

The menu bar hit the sweet spot: always visible, zero screen real estate, instant access.

The Glanceable Design Principle

The hardest design constraint was keeping it glanceable. Every feature request I considered got filtered through one question: can you understand it in under two seconds?

Detailed service health metrics? No. Up/down is enough.
Historical quota graphs? No. Current number is enough.
Configuration UI? Minimal. Edit a config file if you need custom services.

The result is intentionally boring. No charts. No tabs. No settings pages. Just the current state of the things you care about.

Technical Details

15MB binary — native SwiftUI, no Electron runtime
~12MB RAM idle — sits in the menu bar without impact
Sub-second startup — feels like part of the OS
Polling-based — checks services on a configurable interval (default 30s)
Open source — github.com/silas-maven/pulse

One Week In

The change was subtle but real. I stopped context-switching into browser tabs I didn't need. I caught a dead Redis instance before it cascaded into test failures. I noticed I was burning through Claude Code quota faster than usual on a Thursday and adjusted before Friday's session.

None of these are dramatic improvements. But removing small daily frictions compounds. Five tabs, five times a day, five days a week — that's 125 unnecessary context switches I'm no longer making.

If you're on Mac and running local services alongside AI coding tools, give it a look. It might save you the same friction it saved me.

Repo: github.com/silas-maven/pulse