DEV Community: Silas C

I replaced dashboard-tab checking with a menu bar glance for AI coding workflows

Silas C — Fri, 01 May 2026 02:29:35 +0000

When I am deep in a coding session, context switching is expensive.

I kept bouncing between provider dashboards and terminal checks just to answer basic operational questions:

Are my local services still running?
How close am I to quota limits?

That loop sounds small, but repeated enough times it kills flow.

The problem I wanted to remove

Most tooling gives you information, but not at the point where you need it. For me, the point of need is the menu bar, not another browser tab.

Terminal checks are great, but they are reactive. I only run them after something feels broken.

Dashboard pages are detailed, but they are also heavy. They pull me out of implementation mode and into monitoring mode.

What I built instead

I built Pulse as a native macOS menu bar utility that does one thing well: give me immediate visibility into local service health and AI quota state.

The design goals were strict:

Keep it native and lightweight (SwiftUI, no Electron)
Keep interaction latency low
Keep the surface area small

If a tool needs a manual to explain itself, it is already too much for this job.

Why native mattered here

A lot of dev utilities become mini platforms over time. That can be useful, but this one is intentionally narrower.

Native gave me a few practical wins:

Better memory behavior for always-on usage
Faster startup and interaction
Cleaner fit with macOS menu bar ergonomics

Tradeoff: macOS-only scope for now.

Workflow change: before vs after

Before:

Open provider dashboard
Check usage
Switch back
Notice an endpoint failed later
Open terminal and inspect process/port

After:

Glance at menu bar state
If red, restart or inspect immediately
Keep coding

This is not a dramatic productivity story. It is a friction-removal story.

What I learned building this

Visibility beats volume of metrics. A few high-signal indicators are better than a crowded panel.
Status language matters. “Probably fine” UI states are useless; explicit states are better.
Small reliability tweaks compound. Better refresh cadence and clearer state transitions reduce false alarms.

What I would improve next

More provider-specific quota normalization
Better handling for edge states (partial auth, stale refresh)
Optional historical trend view without turning it into a dashboard

If you are building similar tooling

Start from the context-switch you hate most.

Then remove exactly that, with the smallest possible interface.

For me, that was replacing scattered checks with one menu bar glance.

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

How to manage CV variants without spreadsheet drift (manual tailoring burnout)

Silas C — Fri, 24 Apr 2026 15:21:10 +0000

How to manage CV variants without spreadsheet drift (manual tailoring burnout)

Publish a practical dev.to guide: how to manage multiple CV versions without spreadsheet drift. Include naming convention, role buckets, and quick QA checks before apply.

If your job search has more tabs than interviews, this is for you. I wanted a workflow that stays simple under pressure and still gives useful feedback.

The problem

Most people run into three issues:

Too many CV versions
No record of which version was sent
No weekly loop to improve outcomes

The minimal system

Use one master CV and 2-3 variants by role family.

File naming

Use deterministic names:
Role_Company_Date.pdf

This prevents duplicate applications and gives you instant history.

What to tailor

Do not rewrite the full CV each time. Tailor:

Summary (2-3 lines)
First 3 impact bullets
Skills ordering

Keep everything else stable unless your weekly data says it is broken.

A weekly feedback loop

Every week, check:

applications sent per role family
response rate per role family
interview conversion by CV variant

If one variant underperforms for 10-15 applications, adjust language before increasing volume.

ATS score, used correctly

Treat score as a hint, not a verdict. The practical order:

Ensure clear structure
Match role language naturally
Add proof in bullets (numbers, scope, outcomes)
Then check tooling output

Example change

Before:
"Worked on reporting dashboard."

After:
"Built reporting workflow used by 4 teams, reducing weekly manual analysis time by 35%."

Same task, better signal.

Common failure modes

Creating a new CV from scratch for every application
Tracking applications from memory
Mixing unrelated role families in one variant
Overfitting to one score tool

Practical template

Master CV
Variant A (backend)
Variant B (product)
Variant C (ops/client-facing)
Application log (company, role, date, variant, next action)

Final note

You do not need more hustle. You need a stable process you can run when stressed.

A boring system beats a heroic one every single week.

Extra implementation notes

When you review outcomes, change one variable at a time. If you change summary, bullets, and skills together, you lose causality and cannot learn what worked. Preserve a changelog with date and reason for each adjustment. Over a month, this creates a reliable map of what your market responds to.

Also, keep your role buckets tight. If you apply to backend, data, and PM roles with one variant, your language signal gets muddy. Three clean buckets usually outperform one broad CV.

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