In the Age of Fast AI, How I Built Mole as a "Slow Product"

In the Fast AI Era, How Did I Make Mole a "Slow Product"?

It's been over two months since I finished my last post on SSPAI, "From an Open-Source Cleanup Tool to a Paid Mac App: What Users Taught Me About Building Products." During this time, Mole went from 1.13 all the way to 1.19, adding AI tool cleanup and system data cleanup, the Windows version also shipped on the evening of October 14, and the GitHub Star count suddenly reached 73.9K.

Looking back at this period, what took the most time wasn't writing new features, but rather testing software, sending follow-up emails, and tweaking icons and copy—silly things that engineers consider a poor trade-off.

Programmers naturally like doing scalable things, wanting to solve everything by making it as tool-based, automated, and AI-driven as possible, so they can be lazy. My feeling after these two months is a bit different: code is getting cheaper and cheaper, anyone can quickly build something that runs, and what increasingly sets you apart is the details that only those who have done it firsthand know. Fortunately, with AI, these silly things that used to require a lot of manpower can now be done by one person alone.

Installed 853 Mac apps to test uninstallation

I'm a bit OCD in daily life, and I always keep the software on my computer to around 30. To make Mole's uninstallation more thorough and its residual cleanup stronger, in the first round I compiled over 300 Mac apps from home and abroad, downloaded over 100 GB, divided them into 30 groups of 10 each, and had the Agent use its computer use capability to download them from official websites, install them one by one on my computer, check directories, update bundles, check launch agents, then uninstall, find the remaining residuals, and add the missing rules into Mole.

At the time I thought testing at most 100 mainstream apps would be enough, but after finishing I thought maybe another 100, and by the time I reached 200, I thought another 100, and later I added App Store versions and extensions, all the way to 549, 709, 824, and now 853 apps. My computer suddenly turned into the very messy desktop below, haha, let me show you all.

This process looks very boring, many apps immediately flood you with permission popups once installed, nudging you to buy a membership, and some even require entering the admin password; the Agent could handle most of it on its own, and I helped out with a small portion. What pleasantly surprised me was that AI also wrote automation scripts for installing, uninstalling, and checking residuals on its own, making its job easier—pretty smart, haha, so I could only play a supporting role.

I originally thought software engineering should be standardized and orderly, and after running 100 apps there should be no more rules to add, because logically the development standards of mainstream software could be fully enumerated. But the further I went, the more I found this wasn't the case at all—many residuals can't be fully found no matter how you write general rules, and some bundle IDs aren't even reverse domain names; what looks like a well-standardized convention may just be something a programmer wrote casually back in the day, with no theory to explain it, so you can only install one and check one.

After testing over 300 apps in that round, Mole gained 13 categories of reusable general rules and over 90 precise cleanup paths, and I also fixed over 30 places that were originally thought to need cleaning but actually shouldn't be touched, plus added over 100 unit tests. Those places that shouldn't be touched are just as valuable to me as newly found residuals: caches can be regenerated, but users' own files cannot, and data shared by several apps certainly shouldn't be cleaned just because one of them is uninstalled.

I also compiled the specific residual paths and manual uninstall steps for each app into Chinese and English guides on the official website; all 853 are now available for free, so even without the tool, you can follow the steps to delete them cleanly by hand. You all can check whether the software on your computer is on this list.

Actually used all 30-plus AI tools

Before building AI cleanup, many friends had mentioned wanting to clean AI tools' data. Previously, in my view, AI Coding session records were very important assets, so this area only cleaned real caches and old versions.

But as I use AI every day, I've accumulated a lot of not-so-useful old artifacts, old sessions, and worktrees locally, and one user's opencode.db grew to 62 GB as a single file and urgently asked how to clean it. So I tested over 30 AI tools one by one, including 13 desktop apps and 13 command-line tools, and also checked the directories left behind after uninstalling OpenClaw, Hermes, and Pi.

Unlike the previous install-then-uninstall approach, this time I logged into accounts for all the tools I could use, used each once in a real project—asking questions, running Agents, building code indexes, setting up scheduled tasks—because a lot of data is only generated after actual use.

For each one installed, the AI compared against the state before installation, measured what it wrote to the home directory, ~/Library, /usr/local/bin, and shell config, recorded it in a ledger, then checked how many processes and how much memory it occupied, and finally uninstalled it with Mole; after uninstalling, it scanned the entire home directory by name to find things not listed, added whatever was missing into the code that night, and re-tested.

The most intuitive finding was memory: 13 desktop apps open at the same time took about 23 GB in total, and one tool from a major domestic company started 41 processes and took 4.49 GB of memory on launch. Most of these tools are VS Code or Electron based, with a long chain of helpers behind one window, so later when building status monitoring, I made each App occupy only one line and combined all its child processes into one count; otherwise, just looking at Activity Monitor, you couldn't tell who was actually eating memory.

There were also the small changes they make to the system. Some tools, when opened for the first time, put a root-owned command link in /usr/local/bin, and after the App is deleted this link becomes a dead link; one put a python3.12 in ~/.local/bin, and afterward typing python3.12 in the terminal actually ran its bundled version; the most outrageous was a certain domestic command-line tool—I ran it once, it first told me it was no longer maintained, then without asking me at all, it directly downloaded and installed its new version, modified .zshrc, and even renamed the original command to legacy.

The sizes were also outrageous. One desktop app downloaded about 1 GB of tool packages the first time I used Work mode, which was 3.1 GB after extraction, stuffed with a whole bundled LibreOffice, FFmpeg, and OpenJDK; my own ~/.codex, which I use every day, is already 24 GB, of which sessions take 17 GB; of Claude desktop's 14 GB, 12 GB is the Cowork virtual machine. Many skill installers also write a copy of skills/ into every Agent's directory, whether or not you have that Agent installed, so even though I had clearly never used Qwen Code, iFlow, or Droid, their config folders were all there in my home directory, and Mole's first version even treated them as 2.4 MB of tool residuals, almost cleaning up the skills I had installed as junk.

Processes were also something I didn't expect. When I checked again the next morning after uninstalling, two command-line tools' directories had been deleted and then grown back, because the session processes opened in the terminal the night before were still alive; the program files were already in the Trash, but the background process was still writing logs into the directory—command-line tools have no window, and closing the terminal tab doesn't necessarily end it.

During testing I also encountered some really excessive software: some, when you download the installer, quietly write something to the clipboard to track the installation channel; some, after installation, flood you with popups telling you to join activities to get Tokens, giving a feeling of having to hold your nose while using them. By comparison, Claude, Codex, and Cursor are all fairly restrained, and domestically, Qoder surprised me as quite good—clean interface, on-point aesthetics, nothing out of line.

These also made me change a previous judgment: sessions are indeed precious, but used-up old sessions and worktrees do take up space. In the current AI cleanup, sessions are listed by the retention period you choose—15, 30, 90, or 120 days—each with a title and time, and a recovery copy is kept before deletion; worktrees only appear when git can prove there are no uncommitted changes inside; for opencode.db, it does database compaction, only returning freed pages to disk, not deleting conversations on the user's behalf.

Mac system data can now also be seen and cleaned

A while ago I was browsing Reddit and saw many people complaining that System Data in Mac settings is often one or two hundred GB, asking what exactly it is and whether it can be deleted. But this number is actually just a categorization result; Apple's official explanation also counts all files not assigned to other categories into it, so it's not a list you can delete from. Therefore, Mole's system data grouping only states how much it has measured it can handle, and doesn't force itself to match that total in System Settings.

The hard part is that this area can't be tested by installing one and checking one on my own computer—every Mac's system data is different, and many cases can only wait for users to report them, then be investigated layer by layer.

Article title: In the Age of Fast AI, How Did I Make Mole a "Slow Product"?

For example, with reclaimable space, the figure reported by the system mixes in files iCloud can reclaim and caches the system will free on its own—even on a Mac with not a single local snapshot, that number comes out to around 142 GB. Early versions of Mole used it to estimate how much snapshots could clear, and the estimate came out to 50.7 GB; after clearing, available space actually increased by only a few GB. Now the snapshot row no longer shows an estimated size; after clearing, it directly measures how much the disk's available space actually changed, and since APFS doesn't return space all at once after deletion, it only counts once the number stops growing. Along the way we caught a bug: reading available space kept returning a cached old value, so after clearing it always showed 0 freed.

Another user's system data had 179.53 GB of wallpaper rendering cache piled up—6,644 files in total, one uncompressed BMP stored for each wallpaper and each screen size, and the system itself never deletes them. The first version could scan it out but couldn't delete a single byte, because the wallpaper process keeps running in the background, and the command that checks file usage errors out on individual files, so it was treated as uncertain. In the end we changed it to list only files older than a week and not currently displayed, and hand them to the user for confirmation; this is already available in 1.17.

As for things like the 119 GB of iPhone backups and 79.5 GB of Parallels virtual machines on my own computer—these are large, but they shouldn't be handed to a select-all delete button. Mole only shows their size and a management entry point; they can't be checked, and they aren't counted in reclaimable space, so people go back to the corresponding place and confirm for themselves.

Sending follow-up emails to over 400 users who hadn't activated

During the National Day holiday, I spent a day doing something I'd put off for a long time: going through Mole's orders from when sales started in May through the end of September that had been purchased but not activated—about 400-plus orders. I used AI to write a simple local script to list the user emails and Keys, then, by purchase month, country, and language, sent them out one by one, just like sending a WeChat message, telling users not to forget, and that there was no rush to use it.

Interestingly, I received a great many replies from users in various countries, which was far more meaningful than I'd expected. Some users said they bought it just to support me in continuing development and preferred using the Terminal version; others had completely forgotten about the GUI and had been using the CLI all along. Some users were very thoughtful—they bought two, one for themselves and one for family, planning to give it as a Christmas gift, so they never activated it; the Key was already saved in their password manager. It made me feel the world is truly wonderful.

Some users first used it on their work computer, then their company banned software not on the approved list, so they'd been waiting for their own new Mac; others bought it during my discount and don't yet have a MacBook, planning to activate it as soon as their new machine arrives. Someone replied with a "Prefect!", and someone else said during the National Day holiday that one should also have a good mo(mole) during the holiday—these replies all made me happy.

But quite a few users had actually entered their email wrong—perhaps typing too fast, writing gmai.com, gmail.con, cloud.com, and the like—and never came to me about it; some users didn't receive the first email and bought it again just to start using it sooner.

So following from this, I filled in a bit of the post-purchase flow: after payment completes, it automatically jumps back to the official website page and directly displays the Key, so even if a user entered the wrong email or the email was blocked, they can see it right after purchase. Along the way I also added a fun little detail: when a user clicks activate on the webpage, it can wake up the installed client with one click and automatically fill in the Key on the activation page—no need to copy and paste, just click the confirm button.

This little magic trick is really just the webpage handing the system a link Mole can recognize, the system handing it to the client, and the client only putting the Key into the input field—it won't auto-confirm activation on the user's behalf; in the end it still goes through the original license validation. Engineers who've written clients and frontends might find this technical implementation simple, but to most users it feels like whoa, amazing, magic—this product did a little extra for me.

There are also some small details in Mole that I don't know if everyone has noticed: when you start cleaning the screen, the whole screen goes black, then the keyboard locks, and a random line of poetry appears on the screen—just enough time for you to read it and think for 2 minutes, and the screen is clean.

Recently I've been doing something similar: writing letters to the group of early users who bought Mole as soon as it launched in May. I wrote one each in Simplified Chinese, Traditional Chinese, English, Spanish, and French. The letters mainly thank them for supporting so early, mention that over these months the Mac version added system data and AI cleanup, which they can get by checking for updates in Mole, and end with a line saying that if anything feels awkward to use or they want any new feature, just reply and tell me.

I wrote this letter myself by hand, just like talking to a friend.

Paul Graham wrote in Do Things that Don't Scale that Wufoo hand-wrote thank-you notes to new users early on, and Stripe would take a user's computer on the spot and help set it up directly.

Redrawing icons and revising copy based on user feedback

The detail I spent the most time on these two months was replacing the entire icon set in Mole. Before, I used system icons, which were completely sufficient for simple scenarios, but on closer look they lacked a bit of spirit. After researching, Remix Icon is used a lot when writing for the web, but on an App it didn't feel very good-looking, so I ultimately chose Phosphor—about 70% could be used directly, and the remaining 30% I drew myself as SVGs with Opus 5.5, so the overall line width and style would be consistent.

For "Keep Awake," you see, I used a cup of coffee—a kind of Caffeine metaphor, making the computer seem like it drank coffee and can't sleep; for "About," people usually use a circled i, but I thought it should be hello, so I used a waving hand symbol; for "Diagnostics," normally a troubleshooting symbol would be used, but here I used a stethoscope, more like giving the computer a checkup.

After I sent it out, though, there were several icons I thought were quite good but users found not intuitive enough: "Check for Updates" used a download icon and was read as download; the GPU's little square didn't look like a graphics card; the archive icon was incomprehensible; two stacked memory sticks didn't really look like memory; and some said the sponge for cleaning the screen and the waving hand for About were incomprehensible.

So these were all revised again based on everyone's suggestions: Check for Updates became a clockwise arrow, GPU was drawn as a dual-fan graphics card, the archive became an archive box, audio changed from a musical note to headphones, clean screen went back to the original brush meaning, memory went back to a chip, and About finally went back to the most orthodox ⓘ, just redrawn to match the line width of the whole column—many of them were changed three times back and forth, and finally it felt right.

The copy went through the same折腾. I'd nearly used up Claude and Codex quotas writing code, so I dug out Gemini, which had been gathering dust for a while, switched to 3.8 Flash High, and tried having it look at the copy for me—and I was very pleasantly surprised: it may not be top-tier at writing code, but it writes plain language very well. I went through almost all of Mole's settings items, cleanup item descriptions, and website content, with a simple requirement: speak like a human—simple, clear, easy to understand, so even a first-time user gets it instantly; no flowery language, and no AI flavor.

I had it output before-and-after comparisons and the reasons, then went through them one by one—it really felt like having a very patient language teacher sitting beside me, helping me turn many programmer-self-indulgent expressions into words normal people can understand. For example, the cache deletion item: the original wording was easily misunderstood as the way to delete the entire App; now it clearly states that it only handles ordinary caches on the cleanup page, and uninstalling is unaffected.

Accessibility attributes make AI testing more accurate

When testing hundreds of pieces of software, there was another unexpected gain. The first few versions of Mole already began supporting visually impaired users and added many accessibility attributes—unexpectedly, this helped a great deal this time: with these attributes, AI can locate the position of every button and element very accurately, and testing went much more smoothly.

Accessibility attributes provide not just a coordinate, but also what the control is called, what type it is, and what state it's in now; if the interface changes slightly, the script can still find the same button. If you rely only on screenshots and coordinates, once a popup changes or a window moves, it's easy to click off-target. Apple thought from the very beginning that everyone should be able to use a computer equally, and many places can be read by VoiceOver—that's really great.

Testing the Windows version on virtual machines and a ThinkPad

When making the Windows version, it was also tested out one by one like this. Actually, the Windows side didn't start from zero: Mole's Windows CLI began being maintained gradually early in the year, with community members contributing together, and now the CLI is already quite mature—having this foundation is what made this desktop version possible. The desktop version uses Windows-native C# and WinUI 3; almost none of the Mac version's Swift code could be used, and it took about a month of back-and-forth writing, accumulating over 90,000 lines of code and more than 5,500 test cases. Most of the 482 Windows programs tested were run in a Parallels virtual machine on a Mac; I bought a ThinkPad X1, kept it running 24 hours a day, connected to it from the Mac via UU Remote and ssh, and had AI directly operate this real computer to do installation, uninstallation, and cleanup acceptance testing.

Before release, the Windows version actually iterated through about 14 versions within a small group, then went through multi-day beta testing with Mole angel users, who offered a great many suggestions, and it's finally about usable—thank you all so much for your help!

In the Age of Fast AI, How Did I Make Mole a "Slow Product"?

Right now my Mac is the main machine for all R&D. It runs a Parallels VM, is connected to the ThinkPad X1 next to it, and has a small Android tablet plugged in via a cable; with adb debugging enabled, AI can help me operate some services that have no API. Add the iPhone simulator in Xcode. All AI context lives on this one Mac. Normally I have 7 to 10 tabs of Agents running tasks in the terminal. Suggestions and feedback collected on social platforms go into Notion, and AI automatically marks them as done after handling them.

I wrote about the specific approach to developing Windows software on a Mac—such as how to layer the code so tests can run on a Mac, and how to drive the VM with scripts—in this post on the Mole blog. I also discussed the trade-offs in technology choices in Client Development You Don't Know. Anyone with the same needs can take a look.

In an Age Where Code Has Few Moats, Do More Things That Don't Scale

On the contrary, I think that in this era where code has few moats, we can do more things that don't scale. Only by going through them manually yourself can you know how to better optimize the user experience; you can't figure it out just by thinking.

Installing and uninstalling 853 apps one by one, reading every reply I receive, revising dozens of icons over three rounds—AI won't decide to do these things for you, but after they're done, if they can make 1% of users, while using your product, occasionally experience a feeling of instant