The unglamorous infrastructure problem every creator eventually hits — and what a tiny Mac utility taught me about tooling discipline
Somewhere between your third repurposing workflow and your fifth scheduled cross-post, the machine you actually create on starts to betray you. Not dramatically — no smoke, no crash. It just gets… full. And for the overwhelming majority of people reading this, the culprit is not the 4K export folder or the CapCut cache. It’s the invisible debris of the modern creator stack: the simulators behind that one app you built for a brand deal, the Docker containers from the data pipeline you swore you’d finish, the node_modules graveyards from every half-shipped side project. I’ve watched this happen to my own machines and to the machines of the solo founders I advise. So when a maker named Otabek Abdiraimov launched Shedi on Product Hunt — a Mac cleaner built specifically for developer clutter — I paid attention, not because it’s a social media tool, but because the reasoning behind it is a masterclass in how to build tools for people who don’t have time to think about tools. That’s the lens I want to use here, because it’s the lens that should govern every piece of SaaS you buy.
The problem Shedi actually solves — and why it’s a proxy for the whole creator-tooling market
Let me be precise about what this product is, because the framing matters. Shedi is a macOS disk-space cleaner. The maker’s own origin story, as he tells it on the launch page, is that his MacBook kept running out of space and the recurring offenders were Xcode simulators, DerivedData, Docker, and node_modules. The big, well-known cleaners, in his words, “didn’t know about any of it, cost a lot more, and wanted me to trust one giant Clean button.” His first scan on his own Mac surfaced 21.5 GB — a number that will sound familiar to anyone who has ever opened Xcode’s DerivedData folder and felt a small existential dread.
The design philosophy is the interesting part, and it’s the opposite of the magic-button approach:
- It knows where “20+ developer tools hide space” — Xcode, Docker,
node_modules, npm, pnpm, Homebrew, Cargo, Gradle, and more. - Every item is labeled with what it is, whether it’s safe, and whether it comes back.
- Only things that rebuild themselves are pre-selected; the user’s own files never are.
- Deletion goes to the Trash first, so it’s reversible.
- No account, and files never leave the Mac.
- There’s a playable demo on shedi.app before you download anything.
Pricing is an early-bird mechanic: the first 50 buyers get $10 off at checkout, and the site shows how many spots are left. The maker also flags, with refreshing candor, that the app isn’t notarized yet — his Apple Developer ID is pending — so first launch requires the System Settings › Privacy & Security › Open Anyway dance. The notarized build will be a free update.
Now, why should a social media operator care about any of this? Because the shape of the problem is identical to the one you face every quarter when you audit your stack. You have accumulated tools you don’t remember installing. You have workflows that silently consume time and attention the way DerivedData consumes gigabytes. And the market keeps selling you the same thing Shedi’s maker was reacting against: the giant, opaque, one-click button that promises to fix everything and asks you to trust it. My take: the most valuable skill in the creator-tool economy right now is not finding new tools — it’s developing the same “what is this, is it safe, does it come back” literacy that Shedi forces on its users.
Why the “safe to delete / comes back” labeling is the real product
Strip away the disk-cleaner specifics and Shedi is selling a decision framework: for every item, what is it, is it safe, will it regenerate? That triad is exactly what you should demand from every scheduling tool, every analytics dashboard, every AI repurposing service. When Buffer or Later or Metricool asks you to connect an account, the honest question is: what data does this pull, is revoking it safe, and does my content survive if I leave? When an AI tool offers to “repurpose this video into 10 posts,” the question is whether the output is yours to keep and whether the source is retained. Shedi’s transparency model — label everything, pre-select only the self-healing stuff, send deletion to Trash first — is a UX pattern I’d genuinely like to see imported into the social SaaS category. Most tools do the opposite: they pre-select the maximum and bury the reversibility.
How it differs from the incumbents — and the honest gaps
The obvious comparison set is the mainstream Mac cleaners: CleanMyMac X, DaisyDisk, and the various App Store “cleaner” apps. The maker’s claim is that these “didn’t know about” developer-specific clutter, cost more, and relied on a single trust-me button. I haven’t benchmarked Shedi against CleanMyMac on an identical machine, so I’ll flag that as his claim, not a verified fact — but it’s a plausible one, because the mainstream cleaners are built for a general audience and their scanning heuristics are tuned for caches, logs, and large media files, not for the nested, symlinked, hard-linked weirdness of a modern dev environment.
And that weirdness is exactly where the most interesting limitation shows up. In the launch thread, a commenter named Lukáš Gurecký raises a genuinely sharp technical objection: he had Claude clean his MacBook, freed about 100 GB, but now has to run pnpm i every time he opens an older project. He asks two questions — can Shedi preselect node_modules in projects untouched for, say, 30 days while keeping active ones, and does Shedi account for the fact that pnpm hard-links most of node_modules to a global store, so deleting the folders frees less disk space than their displayed size suggests? That second question is the kind of thing that separates a real tool from a demo. If Shedi reports raw folder size for pnpm projects, it will overstate reclaimed space, and users will notice. As of the scrape, the maker hadn’t publicly answered in the captured thread — so I’d call this an open question, not a confirmed flaw. But it’s the first thing I’d test.
Where the math breaks
Here’s the operational lesson hiding in that comment, and it applies directly to your analytics life. A number that looks authoritative can be structurally wrong. node_modules displayed at 2 GB might free 200 MB if it’s hard-linked. A “reach” figure in your dashboard might double-count impressions across surfaces. An “engagement rate” might use follower count as the denominator when the platform’s own algorithm only distributed to 4% of them. The discipline Shedi is being asked to adopt — count actual reclaimed space, not apparent size — is the same discipline you should apply to every metric you report upward. In my experience, the fastest way to lose credibility with a client is to celebrate a number that doesn’t survive a follow-up question.
What creators and social media teams can borrow from Shedi’s design
I’ve now run enough social stacks to have opinions about tool design that have nothing to do with features. Three patterns from Shedi are worth stealing outright.
First: pre-select only what regenerates. Shedi auto-selects rebuildable artifacts and never the user’s own files. Translate that to your content operations: when you build a repurposing pipeline, the source of truth — your raw footage, your master doc, your original audio — should never be the thing a tool touches by default. Everything downstream (the vertical crop, the caption variants, the thread version) is regenerable from the source. If your workflow can’t regenerate a derivative from the master, you don’t have a pipeline, you have a pile. This is the same logic that makes CapCut templates and Canva brand kits useful — they’re regeneration surfaces, not archives.
Second: Trash-first reversibility. Shedi sends deletions to the Trash so you can put things back. The social equivalent is scheduling with a real undo window and draft states, not “publish now and pray.” When I scheduled 30 posts across five platforms last month, the single most valuable feature wasn’t bulk scheduling — it was the ability to pull a post back after a typo without deleting and re-creating it, which resets any platform-side review state. Reversibility is a feature. Demand it.
Third: no account, data stays local. Shedi’s no-account, files-never-leave-your-Mac stance is a positioning choice, and it’s one more social tools should be pressed on. Every OAuth connection you grant is a data surface. When you audit your stack — and you should, quarterly — ask which tools actually need write access and which are just hoarding tokens. My take: most teams over-grant because revocation feels like work.
Why the solo-founder framing matters more than the feature list
The maker notes he builds Shedi on his own and also makes Halo, a notch app. That context isn’t incidental — it explains the product’s entire personality. Solo builders ship opinionated tools because they are the user. The “20+ developer tools” list isn’t a market-research artifact; it’s a list of things that personally annoyed him. This is the same dynamic that produces the best creator tools: the ones built by people who actually publish. It’s also why I’m skeptical of enterprise-grade social suites that add features by committee. The indie-founder lens tends to produce sharper defaults and more honest limitations pages. Shedi telling you upfront that it’s not notarized yet and giving you a 30-second guide to the Open Anyway flow is the kind of transparency that big-vendor marketing teams would never approve — and it builds more trust than a badge would.
Where my judgment says it falls short
Balance time. Shedi is a young, single-purpose Mac utility, and I’d be doing you a disservice to pretend otherwise.
- Not notarized at launch. The maker is upfront that his Apple Developer ID is pending. That’s a real friction point for anyone in a managed IT environment, and a legitimate reason some users will wait. It’s also a trust hurdle: “Open Anyway” is exactly the instruction malware uses, so training users to click through it is a habit with externalities.
- The pnpm/hard-link accounting question is unanswered in the captured thread. Until it’s addressed, I’d treat reclaimed-space figures for pnpm projects as approximate.
- Single-platform by design. This is macOS-only and developer-focused. If your “creator stack” is a phone and a ring light, this is not your tool — and that’s fine. Knowing who a product is not for is as important as knowing who it is for.
- The “20+ tools” claim is unverified. The launch page lists Xcode, Docker,
node_modules, npm, pnpm, Homebrew, Cargo, Gradle “and more” — the full list isn’t enumerated in the scrape, and I haven’t independently confirmed coverage depth for each. The playable demo on shedi.app is the right place to check before buying. - Pricing beyond the early-bird discount is not disclosed in the source. The first 50 buyers get $10 off at checkout with a live counter, but the base price isn’t stated in the scrape — verify on the site.
None of these are disqualifying. They’re the normal shape of a v1 from a solo maker. But if you’re the kind of operator who needs a tool to be boring and audited before it touches a work machine, this isn’t there yet.
What I’d watch / test next
Here’s what I’d actually do this week, whether or not you ever install Shedi.
- Run the same audit logic on your social stack. For every tool with account access, write down: what it pulls, whether revoking is safe, and whether your content survives if you leave. Pre-select only the regenerable. That’s the Shedi triad applied to SaaS.
- Test the pnpm question yourself if you’re a dev-creator. Install the playable demo, point it at a project with a hard-linked
node_modules, and compare displayed size to actual reclaimed space. Report back to the maker — he explicitly asked what it should learn to find next. - Watch whether the notarized build ships and whether the maker answers the hard-link accounting question publicly. Those two signals tell you whether this becomes a maintained tool or a launch-day artifact.
- Steal the transparency pattern. If you build anything for creators — a template pack, a Notion system, a repurposing workflow — label every component with what it is, whether it’s safe to remove, and whether it regenerates. Your users will trust you more for it.
The through-line: the tools worth keeping are the ones that respect your judgment instead of replacing it with a big button. Shedi is a small Mac cleaner making that argument in a niche most of you will never touch. The argument itself is the thing worth carrying into your own stack.
