Recently, I've written quite a bit about my thoughts on independent development. I wanted to summarize them by talking about the journey of Mole from an open-source CLI to a paid Mac software—what I was thinking at the time, what actually worked, and perhaps provide some input for friends who are working on their own projects.
Mole's official website is
mole.fit , and the CLI is open-sourced on
GitHub . You can give it a try first.
Last year during the National Day holiday, I wrote a few hundred lines of code by a swimming pool in Sanya and created a Mac cleanup command-line tool called Mole CLI, which I open-sourced on GitHub. I originally only intended it for myself and my colleagues. As it turned out, in less than a year, it garnered 60K stars, released over 50 versions, and had 121 developers from around the world submit code, resolving nearly 800 feature suggestions and bugs.
Actually, I didn't quite realize how many people were using it until one time, because I had two images in the README accelerated by Vercel, the traffic exceeded the billing limit, and I owed Vercel $80. That's when I realized it was time to build a desktop version.
Previously, the most common type of email I received was from international users, with the general sentiment being: "My parents use Mac, my sister uses it too, but they don't know how to open the terminal. Can you make a version that doesn't require typing commands?" I delayed this for a while, mainly because I felt the CLI itself wasn't mature enough. Later, I spent two weekends building the Mac desktop version. I released it at 10 PM that night, and notifications kept ringing all night—French, German, all sorts of currencies. I eventually turned off email notifications just to get some sleep. Looking back, that initial release was actually quite thin; how complete can something built in two weekends be? Many features were added bit by bit over the following months. It was essentially a group of users paying first and then accompanying me to finish it. The CLI remains unchanged, still open-source and free, and will continue to be updated; only the desktop version is paid.
Three Types of Junk Created by AI
After the desktop version was built, the feature I used most myself was cleanup, because my Mac was truly being pushed to its limit by AI. I keep Claude Code and Cursor open all day to write things. At first, I didn't pay much attention, but later I discovered that the junk left by AI is very different from traditional software, falling into roughly three categories.
The first category is compilation artifacts. This isn't new, but AI has amplified the scale. Previously, I might hand-write a few hundred lines of code and compile three to five times a day; now, I let an agent run a dozen rounds in an afternoon, compiling once every round. Rust project targets, frontend .next and dist folders, and Xcode's DerivedData grow very quickly. I once cleared out 86GB of just these things. The second category is old versions left behind by AI tools themselves. Command-line tools like Claude Code, Cursor Agent, and GitHub Copilot all auto-update. They update by downloading the entire new version into a new directory—each version is about 250MB—and the old ones aren't deleted. Over a few months, a dozen useless versions can accumulate. The third category is model files—models pulled by Ollama and LM Studio, and HuggingFace caches, which often take up dozens of gigabytes.
Mole cleans the first two categories but doesn't touch a single byte of the third. Later, I gradually thought of this in three tiers, categorizing everything scanned before deciding whether it should be checked by default. The first tier is renewable: HTTP caches, GPU caches, compilation artifacts, and most logs. If the relevant app has exited and the path is clear, it can be cleaned. The second tier has a high reconstruction cost: package manager registry caches, local model weights, and iOS DeviceSupport can all be rebuilt, but it costs bandwidth and time, so the user should take a look themselves. The third tier is irreplaceable: chat history, email databases, photo libraries, and the state of current projects. I believe these things should never be put into a one-click cleanup list.
Compressing these three tiers into a single "safe to delete" list would be easier, but the cost is making the decision for the user. The ten categories on the cleanup page are arranged in this order: renewable caches are at the top, and the further down you go, the more you need to check for yourself.
Things like target, build, dist, __pycache__, and DerivedData can be brought back by recompiling, at the cost of a few minutes of CPU. node_modules, Pods, venv, and vendor also look like dependency directories, but deleting them requires re-downloading from the internet. If you're on a high-speed train or a plane and want to run a project, you'd just be stuck waiting. These two categories look similar and are easily cleared as junk together. Mole CLI did this early on, but later I specifically removed all download-type directories from the Mac version's cleanup list.
Models are the heaviest category here. Re-downloading dozens of gigabytes is a disaster, and a general cleanup tool won't even delete them correctly. Ollama splits models into a bunch of blocks named by hash; multiple models might share the same block. ollama rm calculates whether anyone else is still referencing a block before daring to release it. If you manually delete a large-looking block from the file system, you might break another model. Only the tool itself understands these references.
Therefore, paths like ~/.ollama/models and ~/.cache/huggingface are hardcoded into a protection list in the code. They won't even appear during the scanning phase; they only show their occupied size in the disk analysis section, leaving the models themselves to be managed by Ollama or LM Studio.
There's another category of things even more untouchable than models: AI session records. ~/.codex/sessions, ~/.claude/projects, and ~/.grok/sessions store your complete dialogues with AI over months or even a year. They contain your thoughts at the time, rejected solutions, and the reasons for every change. If deleted, they are truly gone, and in a way, they are more precious than the code itself. So these paths will never be cleaned in Mole, no matter how long they've been sitting there. Also protected are memories, plans, skills, and generated images.
These protection lists weren't all thought of at the beginning; they were mostly learned through trial and error. The silliest mistake was com.apple.e5rt.e5bundlecache. It has "Caches" in the name and is located in the cache directory, so it looks like a cache, but it's actually a model compiled by Apple's Neural Engine. The CLI early on treated it as a cache and cleared it, causing all apps using recognition features to crash until a reboot. Since then, I've developed a habit: when I see a directory with "cache" in its name, I ask myself three questions: Who wrote it? Who will read it after a reboot? How do I get it back if I delete it by mistake? If I can't answer one, I don't touch it.
Look Before You Delete
I don't judge the quality of this type of tool by how much it can clear, but rather by whether it lets you see clearly before deleting.
When Mole cleans, it scans first, lists items one by one, and shows exactly what each item is, where it is, and how much space it takes. Items I'm unsure about are unchecked by default. You confirm before deleting, and when deleting, items go to the Trash first so they can be recovered if you regret it. Scanning and cleaning are done entirely locally; files and results are never uploaded. The cost is that it's slower and requires an extra confirmation step, which might feel tedious when you're in a hurry, but I'd rather miss a deletion than delete something by mistake.
Uninstallation follows the same logic. When you select an app, Mole finds everything scattered across the system, labeling each item with its path and size. In the image above, the Claude app itself is only 781MB, but ~/Library/Application Support/claude is 7.67 GB. It's never the application package itself that truly takes up space. Login items and background services are also on the same page, so you don't have to hunt for them in System Settings.
For example, macOS system update installers—the /macOS Install Data directory—are often over 10GB and look like perfect cleanup targets. But the system might still need them to finish the update; deleting them too early could prevent the machine from booting. So in Mole, it's an unchecked review item with three layers of protection: if there's an update waiting to be installed, the whole row is hidden; if the installer was touched in the last 14 days, it's hidden; if installation-related processes are still running, it's hidden. If any signal can't be read, it's treated as a risk and not displayed at all.
At the moment of execution, the root-privileged script runs these checks again. If they fail, it exits with a non-zero code. You won't see a situation where "the report says 12GB was cleared but not a single byte was moved."
I have a very simple way to judge if a cleanup tool is good. Install two products from the same vendor, uninstall only one, and see if it includes the shared Application Support parent directory or group container. If it does, it means it's matching by name, not by ownership. I don't dare let a tool that can't even clarify ownership delete things in bulk.
It Won't Disturb You Normally
Clearing 86GB at once isn't achieved by deleting a few logs; when uninstalling Claude, you can find things ten times larger than the app itself scattered throughout the system. It will find what it needs to find, but it won't actively disturb you.
Once installed, it won't pop up notifications every few days to remind you to clean, nor will it jump out after a scan to say how dangerous your computer is. Open it when you want to clean; when you don't, it's as if it doesn't exist.
The interface follows the same philosophy. If the scan isn't finished, it doesn't enter the results page. For things that will be ready in a moment, it doesn't even give a loading prompt; only after a while does a "busy" animation appear. The completion page also has space reserved in advance so the window doesn't jump when the results appear. These rules are all very trivial, but together they are why it feels stable to use.
The underlying tasks are inherently unpredictable, so adding animations doesn't help; the process itself must be reliable. I don't want a maintenance tool that requires constant monitoring. Initiate the task, wait for it to finish, and then take back the screen—that's enough. It doesn't need to keep flashing lights to remind you to look at it.
Accessibility is also part of this. The reading order, keyboard operations, and focus stability are all part of the same "quiet" experience. When the system's "Reduce Motion" is turned on, the planets stop their decorative rotation, and state changes reduce spatial movement. No operation depends on the user understanding an animation.
Making It Usable Even for a 70-Year-Old
Previously, when I made things, I basically only considered whether they were easy for my colleagues and friends to use. Moving from CLI to the desktop version, I realized that making it usable for a 70-year-old grandfather involves much more, and it's much more interesting. The following are all pulled from user emails over the past three months; my greatest gains are almost all here.
A British user nearly 70 years old said he had a "senior moment" and bought Mole again. "Consider the second payment a gift to you; thank you for this excellent tool, it saved me many more pounds than CleanMyMac." I suggested he get a refund or give the extra license away. He checked around and replied the next day, "None of my neighbors use Mac, nor do my followers on Bluesky. This round is on me." Receiving such letters makes me feel I must make the product even better to be worthy of that trust.
An American user corrected a misconception I had about regional habits. I always thought Americans had to use Fahrenheit for temperature, so I defaulted to Fahrenheit for the US region. He said: "Americans use Celsius in all technical contexts; only weather and body temperature are exceptions. I was startled to see 110 when I installed Mole. The specs Apple shows Americans are also in Celsius, and fastfetch/neofetch default to Celsius on US systems. I suggest keeping the Fahrenheit toggle but defaulting to Celsius for all regions." I later changed it to Celsius by default with a Fahrenheit toggle. He also sent a follow-up about pricing, saying the number I gave didn't look like a deliberately set price but rather a conversion from another currency. He added, "By 'foreign,' I don't mean anti-Chinese, but that people want to feel the author understands them." To be honest, I just picked that price off the top of my head; I never seriously thought about pricing before making the product. Being called out by a stranger was quite embarrassing—it turns out a price figure also affects user decisions.
A user with mild visual impairment said: "It looks like a very nice app, but unfortunately I can't use it; it seems to have dark mode hardcoded. My system is set to light mode, and I only use apps with light mode." Making Mole dark-only was a deliberate decision; the menu bar panel floats on the wallpaper like a HUD, and dark glass has less glare, eliminating the need for a theme switch. But this reason didn't hold for him. I always felt I was serious about accessibility, yet I completely failed to realize that light mode itself is an accessibility requirement. It's been a while since I received that email, and Mole is still dark-only; light mode is still on the list, unfinished. I feel a bit guilty that a product claiming to care about accessibility has left a user who explicitly said they couldn't use it waiting this long.
A lecturer from a German university applied for an educational license, saying it was "not only support for me personally but also meaningful support at an educational level." It turns out there are international teachers using my product in a classroom environment, a use case I hadn't anticipated. A Hungarian doctor gave the most honest negative review: "To be honest, the price is a bit high for something a free app can also do." I didn't find this harsh at all; purchasing power varies greatly between countries. He wasn't complaining; he was helping me locate a problem.
My favorite features in Mole weren't actually my ideas. The notification when AirPods are low on battery was added while I was working on battery health; I hadn't encountered that scenario until one afternoon I actually received it—it was very thoughtful and not intrusive. I added three different behaviors for keeping the screen on after a user reminder; when I suddenly go out on weekends, the AI coding can continue running, saving me a lot of asynchronous time. Being able to see the iPhone's battery level in the status was difficult to implement at first, but I eventually found a way. These were all things users told me to add, and I ended up benefiting the most from them.
I've Actually Been Replying to Emails Manually
Q&A, refunds, and resetting activation codes account for less than 1% of the user base. I could write a script in half an hour to automate it all, but I haven't. Only by processing them one by one can I feel what users actually want, why they refund, and what makes them uncomfortable—and that's often not the first thing they ask. My threshold for automation is when three things are true: the problem recurs, the answer is stable, and the exceptions are all understood. Until then, I'd rather reply one by one. This is still effective; I haven't spent money on marketing, and growth mostly comes from word-of-mouth. The refund rate is below 0.8%. Many buyers are long-time users of the CLI.
Before the release, I didn't set up a ticket system, customer service platform, or knowledge base. Engineers like to build these support systems first because it's familiar work, and AI has compressed it to half a day, making it easier to start too early. But while it only takes half a day to build, maintenance is a long-term commitment, and it's simply not needed yet. The day the inbox starts losing requests, response times become unclear, or the same question gets different answers—that's when a new system is truly needed. AI makes many parts of this product possible, but communication with people cannot be replaced by AI; otherwise, it wouldn't be interesting. It can improve efficiency, but it's hard to improve mutual feelings and trust. This might also be a way for products born from AI coding to maintain a human touch.
Things I Found Useful to Do
In building a product, I feel coding ability only accounts for about 30%. More effort goes into connecting your own pain points with those of most users, creating something that is easy to use without a manual, and pushing it in front of the right people so they feel it solved a major problem. A product engineer is roughly a combination of researcher, product manager, engineer, operator, data analyst, and business strategist.
What you don't do is far more important than what you do. For a tool that deletes your files, this becomes what you don't delete. Those hardcoded protection lists all came from this rule. I was lucky to read many books on engineering cultivation when I started as a freshman; phrases like "entities should not be multiplied without necessity" and "simplicity is the ultimate sophistication" slowly seeped into my life, work, and code. I feel this even more deeply after making products. The difference between a good product and an average one largely lies in the ability to decide what not to do. Some features are good in themselves, but if they aren't on the main path, I don't include them; otherwise, it easily becomes a pile of features that are hard to maintain.
Another feeling is that you must have a roadmap for the next six months in your head, knowing clearly what to add in each version, which are fake needs, and which features should be placed where they are handy for users. For ordinary users, the one you can use without reading a manual is the good one. Mole's positioning is as a quiet guardian of Mac system maintenance. Many friends have suggested great features that I've politely declined. My goal is simple: if one out of every hundred Mac users is willing to keep Mole, it's already useful enough.
Now, before a feature enters the roadmap, it must pass three gates: there can be no permanent timers, listeners, or sampling overhead if the user hasn't clicked into the feature; you cannot expand privileged helpers or add new system permissions for a small convenience; and you cannot add settings when there are reasonable default values. These aren't universal principles for all software, but rules Mole set for itself. Every additional permanent task, privilege, and configuration requires the user to trust you a little more.
I basically don't save up for "big moves"; I try to release a version every week so that user problems can be solved promptly and I can have a back-and-forth dialogue. Every release, update, and promotion is a great communication opportunity and lets people who haven't seen the news know what you're doing.
In the AI era, code barriers are getting smaller. What needs more control is how to spend Tokens exactly on solving user problems. I don't mind spending more, but it must be spent effectively—for example, discussing requirements thoroughly, digging into data to find the real problem, and writing copy that people understand at a glance. These areas are worth the spend. I see Tokens as an investment, and investments must yield returns.
Mole has been global from day one, and I post more English content than Chinese. My feeling during this time is that the world is huge, the user base is broad, and they are willing to trust you from the start. People you help in passing often become your users later because there was a real interaction. I haven't spent money on promotion; the spikes on X are high but short-lived, whereas things posted to YouTube decay very slowly. As long as the content is good and someone recommends it, it can live there for a long time.
I spent more time on data than I imagined. Looking at sales by dimension and time, combined with traffic data, user comments, all records of interactions with users, reasons for refunds, and all the issues on the open-source side—these are all precious resources. They help me discover many problems I didn't know about and see exactly where the sales funnel is broken.
The last point is more about my own approach. Building an account with deep utilitarianism makes one anxious; I prefer to build it as a brand, with myself as the brand itself. My thoughts, ideas, product updates, insights, interactions, and comments are all adding trust to this brand. Trust is especially important in today's fake yet prosperous AI world. Things that sound amazing but feel average once you click in have already lowered many users' expectations. Even if you have a truly good product, you won't get attention without trust. This can be done for the very long term; as long as you are on the internet, this brand will live—it is the product with the longest lifecycle in your life.
Why Five Planets
Mole desktop currently has five modules: Cleanup, Uninstall, Optimize, Disk Analysis, and Hardware Status. Each module corresponds to a planet in the interface: Cleanup is Earth, Uninstall is Mars, Optimize is Mercury, Analysis is Jupiter, and Status is the Sun. This is related to my childhood love for watching planetary orbits, plus the fact that the first thing I really wanted to learn after learning frontend ten years ago was WebGL. The planetary textures were changed no less than 10 times; I downloaded many from NASA's official website before settling on them. The rotation direction, speed, and flight effects after completion all follow real celestial bodies.
This part could have been left out; a small menu bar tool that cleans with a click would also work. But the cyber junk generated by AI is already enough. Instead of using Tokens to pile up another interface that just barely runs, I wanted to make something a bit more comfortable—not wasting my Tokens, and not polluting your timeline.
I like things to happen naturally rather than pursuing results urgently in a short time; these three months have reinforced that. A while ago, I thought of a sentence: The best job in the world is probably for a continuous learner in a free market to use their judgment, ability, and aesthetics to continuously create value that others are willing to pay for.
The CLI is open-source and free on GitHub, and the Mac desktop version is on the official website mole.fit.
Since this is my first time making a paid product, there might be areas I haven't thought through. I welcome suggestions and advice from experienced friends. The changes mentioned above weren't my ideas; they were all brought by a user's email or an issue. So, never give up the opportunity to communicate with users; listen to their complaints and suggestions to your heart's content—they can help you a lot and make you understand your users better.
