The creator-economy lesson hiding in a Mac menu bar utility
Most days, the tools that matter to social media operators are obvious: another scheduler, another AI caption generator, another analytics dashboard. But some of the most useful lessons come from adjacent software categories — developer tooling, infrastructure monitoring, the unglamorous plumbing that keeps a pipeline alive. That’s why Standfast, a small MIT-licensed macOS menu bar app from indie maker Pedro Perafán Carrasco, caught my eye. It has nothing to do with Instagram Reels or TikTok watch time. But it is a masterclass in a problem every creator and social team faces and almost nobody solves well: the difference between “the process is running” and “the work is actually getting done.” If you’ve ever had a scheduler report “published” while the post never appeared, or a queue look healthy while nothing shipped, this launch is worth ten minutes of your attention. (Source: Product Hunt launch page.)
The real problem: health checks that lie to you
Here’s the scenario Standfast was built for, in the maker’s own words: you host a GitHub Actions runner on a Mac, and ./svc.sh status still says Started — but GitHub has quietly stopped sending it jobs. You only find out when someone asks why a build has been queued for an hour. The process is alive; the registration is dead. The dashboard is green; the work is stuck.
That is a silent failure, and it is the single most expensive class of bug in any publishing operation. I’ve watched this exact pattern play out in social tooling for years. A Buffer queue shows a post as scheduled and then “sent,” but the platform-side API call silently failed because a token expired or a permission scope changed. A Later calendar looks fully populated, but half the posts are sitting in a “needs attention” state nobody checked. A Hootsuite dashboard reports a campaign as live while the underlying Instagram Graph API connection has been quietly rate-limited or revoked. The tool’s internal state says “fine.” The platform’s state says “nothing happened.” And the operator — usually the person who also writes the captions, edits the Reels, and answers DMs — finds out from a client.
What Standfast does, mechanically, is check both sides on every refresh: launchd for the local process, and the GitHub API for the actual registration. When the process is running but GitHub has the runner marked offline, it shows Disconnected instead of a misleading “healthy.” That’s it. That’s the whole trick. And it’s the trick most social tools still don’t implement.
Why this matters more for social operators than for developers
Developers have logs, CI dashboards, and a culture of alerting on failed jobs. Social media managers have a calendar view and a Slack message from a client. The blast radius of a silent failure is different, too: a missed build gets retried; a missed product launch post, a mistimed giveaway, or a scheduled livestream announcement doesn’t get a second chance. The “process says started, platform says offline” gap is exactly where creator reputations go to die — and it’s why I keep telling teams to stop trusting a single green checkmark.
How it differs from the tools you already pay for
Standfast is not a social scheduler, and I want to be clear about that up front — the maker isn’t pitching it as one. But the comparison is instructive because it exposes what the incumbent stack does and doesn’t monitor.
The big multi-platform schedulers — Buffer, Hootsuite, Later, Metricool — are built around content state: draft, scheduled, published, failed. What most of them do not do natively is reconcile that content state against the platform’s actual state on a continuous basis, especially across every network at once. Some do surface per-network errors, and to their credit the better ones have gotten more transparent about failed publishes. But the default mental model is still “our database says it went out,” and the operator is responsible for catching the exceptions.
Standfast’s model is the opposite: it assumes the local signal is untrustworthy and cross-checks against the remote authority every single refresh. The maker also added two operational details that creators will recognize from their own workflows:
- It shows how long the current job usually takes, so you know whether a queue is normal or stuck.
- It shows what’s queued for repository runners (with a token), so you can see the backlog instead of guessing.
- It reports disk usage for
workanddiag, with a cleanup routine that the maker says never touches checkouts — a reassuring constraint for a tool that runs alongside real work.
That last point deserves a sidebar, because it’s the kind of trust signal I wish more creator tools shipped with.
The “never touches checkouts” principle
When a tool offers to clean up disk space, the first question any operator should ask is: what will it delete? Standfast’s answer — it cleans work and diag but leaves checkouts alone — is a design decision that respects the user’s actual work product. In creator terms, this is the difference between a tool that clears your cache and a tool that clears your cache and your drafts folder. I’d bet most social teams have a horror story about a “smart cleanup” feature that ate something it shouldn’t have. The lesson for anyone building or buying creator tooling: a narrow, conservative blast radius is a feature, not a limitation.
Where the math breaks
Standfast is free, MIT-licensed, has no telemetry of its own, and requires macOS 14 or later. It’s installed via Homebrew (brew install --cask perafan18/tap/standfast). Those constraints are fine for its actual audience — developers running Mac-based CI runners — but they also illustrate why this category of “honest health check” hasn’t been productized for social teams. There’s no equivalent free, open, cross-platform utility that reconciles your scheduler’s state against eight different platform APIs. The economics don’t work the same way: GitHub exposes a clean API for runner status, while social platforms expose a mess of rate limits, token scopes, and inconsistent error surfaces. My take: that gap is a real opportunity for someone, and I’ll come back to it.
What creators and social teams can borrow from it
You don’t need to install Standfast to steal its operating philosophy. Here’s what I’d extract and apply to a publishing workflow this week.
1. Cross-check both sides of every publish. Your scheduler’s “sent” status is the launchd side — a local claim. The platform’s actual state is the GitHub API side — the authority. For high-stakes posts (launches, paid promos, time-sensitive announcements), verify on the platform itself, not just in the tool. I do this manually for anything tied to revenue; Standfast is a reminder that the manual check exists because the automated one is incomplete.
2. Distinguish “busy” from “broken” in your own reporting. The maker asked the community a genuinely good product question: when one runner is busy and another is disconnected, the menu bar shows busy, because a running build is usually what someone is waiting on. Should it show the warning first instead? The first commenter, Bruno Bueno, argued for warning-first — “a busy runner isn’t something I’d act on” — and the maker agreed to look at flipping the order. JC of Haplo AI made the same call: a busy runner is working as expected; a disconnected one is the state you need to act on. Translate that to your social dashboard: surface the thing that needs action, not the thing that’s merely in progress. A post “in review” and a post “failed to publish” should never share the same visual weight.
3. Track queue depth, not just queue existence. Standfast shows what’s queued, not just that something is queued. In content terms: knowing you have 40 posts scheduled tells you less than knowing 12 of them are stuck waiting on a missing asset or an expired connection. Build a weekly “stuck queue” review into your ritual.
4. Respect the blast radius of automation. The cleanup that never touches checkouts is the model. When you connect a repurposing tool like Canva or an auto-poster like CapCut’s export-and-share flow, know exactly what it writes to and what it can overwrite. Narrow permissions beat broad convenience.
Why TikTok creators should care more than LinkedIn ones
Here’s an opinion, clearly flagged: the cost of a silent failure scales with how ephemeral and algorithm-dependent the platform is. A missed LinkedIn post is annoying; a missed TikTok upload inside a trending audio window can cost you the entire distribution event, because TikTok’s algorithm rewards early velocity and the window closes fast. YouTube is similar — a scheduled premiere or a timed upload that silently fails means you miss the first-hour watch-time signal that the recommendation system uses to decide whether to push the video further. On LinkedIn, a late post is late. On TikTok and YouTube Shorts, a late post is often dead. That asymmetry is why I’d argue short-form video operators should be the most paranoid about publish-state reconciliation — and the most interested in any tooling that treats “the platform says offline” as a first-class state.
Where my judgment says it falls short
Balance matters, so here’s the honest accounting.
It’s not for social teams — yet. Standfast is a GitHub Actions runner monitor for macOS. If you don’t host a runner on a Mac, it does nothing for you. The maker is explicit about the audience, and I respect that focus. But I want to be clear that this is inspiration, not a recommendation for your social stack.
The single-platform scope is a limitation, not a flaw. It checks GitHub and launchd. It doesn’t check Instagram, TikTok, YouTube, X, LinkedIn, Facebook, Threads, or Pinterest. The category of “cross-platform publish reconciliation” remains unbuilt as a dedicated product, as far as I can tell — not disclosed anywhere in the source, and I haven’t seen a clean incumbent. My take: the reason is API friction. Each platform’s error surface is different, rate limits vary, and token lifecycles are a nightmare. That’s exactly why a tool that solved it would be valuable — and exactly why nobody has.
The busy-vs-disconnected question is still open. As of the launch thread, the maker had agreed to look at flipping the priority but hadn’t shipped it. That’s a small thing, but it’s the kind of detail that determines whether a status indicator actually helps you act. I’d watch for the follow-up.
No telemetry is a trust win and a blind spot. The maker’s “no telemetry of its own” pledge is the right call for a tool that runs alongside your work. But it also means the maker has limited visibility into how people actually use it, which slows iteration. That’s a trade-off, not a criticism.
Who it’s NOT for: social media managers who don’t run CI infrastructure, teams that need a hosted, cross-platform publish monitor, and anyone on Windows or Linux (macOS 14+ only). If you’re in those buckets, take the philosophy and leave the binary.
What I’d watch / test next
Three concrete things an operator can do this week, and one thing I’ll be watching.
This week: Pick your three highest-stakes scheduled posts and manually verify each one on the native platform within an hour of its scheduled time — not in your scheduler, on the platform. Log what you find. I’d bet at least one “sent” post has a discrepancy you didn’t know about. Then audit your scheduler’s failed-publish notifications: are they actually reaching a human, or are they buried in a settings menu?
This week: Restructure one dashboard so that “needs action” states outrank “in progress” states visually. Steal the busy-vs-disconnected logic directly — it’s free and it works.
This week: If you do run Mac-based CI (some creator teams run their own build pipelines for custom analytics or scrapers), try Standfast — it’s free, MIT-licensed, and installs in one Homebrew command. Report back on whether the disconnected-first ordering ships.
What I’m watching: whether anyone builds the social-platform equivalent — a lightweight, cross-platform “did it actually publish?” reconciler that treats the platform API as the source of truth and the scheduler as a claim. The demand is obvious to anyone who’s been burned. The supply is zero. That’s a gap worth watching, and possibly worth building.
