What I learned building a “Mac cleaner” for developers 💡
When I started Room Service, I thought I was building a Mac cleaner for developers.
That sounds simple.
🩻 Scan files
📦 Show what’s big
🚮 Let people delete things
But after working on it for a while, I realized I was solving the wrong problem.
Developers don’t really struggle with cleaning. They struggle with understanding what’s happening on their machines.

A few things became very clear over time:
1. Cleaning is not the problem, visibility is.
Most issues come from things running in the background: watchers, build tools, local servers.
They don’t crash your system. They slowly degrade it.
2. “One-click clean” is not trusted.
People don’t want magic.
They want to see what’s happening before touching anything.
3. Developer storage is very different from normal users.
Xcode, Docker, node_modules, simulators, caches…
These are not “junk files”. They are part of the workflow.
4. Most tools ignore runtime problems.
CPU, RAM, active processes, local servers…
That’s where things actually break, but cleaners rarely touch this layer.
5. The product started changing because of this.
Features like Dev Ports, Build Watchers, Projects, Ops Feed…
They weren’t planned from day one.
They came from trying to understand the real problem.
At some point I realized:
This is no longer just a cleaner.

It’s becoming a visibility and control layer for a developer machine.
Still figuring out where this goes next,
but the direction feels much more real now.
Curious how others think about this.



Replies
That’s a strong pivot in understanding. You didn’t build a cleaner ypou uncovered an observability problem for developer machines. The best products often start as one thing and become more valuable once the real pain reveals itself.
Room Service
@jeanette__walls appreciate this, that framing is really accurate.
yeah this wasn’t the plan at all. once you look closely at dev machines, it stops being about cleaning pretty quickly.