DEV Community: Tw93

How to Build a Slow Product in the Fast AI Era

Tw93 — Wed, 28 Oct 2026 13:55:46 +0000

It has been a little over two months since I wrote the previous post, From Mole CLI to Mole for Mac: What I Learned. In that time Mole went from 1.13 all the way to 1.18, added AI tool cleanup and System Data cleanup, the Windows version shipped on the evening of October 14, and the GitHub repository quietly passed 72.9K stars.

Looking back, most of my time did not go into new features. It went into things that look like a poor trade to an engineer: installing 850 Mac apps from China and abroad one by one, using each a little, then uninstalling it; resending more than 400 unactivated license emails one at a time; redrawing dozens of icons over three rounds; and rewriting the interface copy line by line until someone opening Mole for the first time could follow it.

Programmers naturally like work that scales. Whatever the task, we look for a way to turn it into a tool, a script or an AI call so we can be lazy. These two months left me feeling a bit differently. Code keeps getting cheaper and anyone can quickly build something that runs, so what sets products apart is more and more the details you only learn by doing the work yourself. The good news is that with AI, these chores that used to take a lot of people can now be finished by one.

From 100 apps to 850: software engineering has no real standard

I am a bit obsessive and keep my own Mac at around 30 apps. To make Mole's uninstall more thorough and its leftover cleanup stronger, the first round collected more than 300 Mac apps from China and abroad, about 100 GB of downloads, split into 30 groups of 10. An agent used computer use to download each from its official site, install it on my Mac, check its folders, update bundles and login items, uninstall it, look for what was left behind, and add the missing rules to Mole.

At first I thought 100 mainstream apps would be plenty. When those were done I thought, why not another 100, and at 200 I thought the same again. Later I added App Store versions and extensions, and the count went to 549, 709, 824, and now 850. My Mac suddenly turned into the very messy desktop below. Have a look.

The process looks extremely boring. Many apps start popping up permission requests the moment they are installed, nudge you to buy a membership, and some insist on an administrator password. The agent handled most of it on its own and I stepped in for the rest. What surprised me most was that the AI wrote its own scripts to automate installing, uninstalling and checking leftovers, to make its job easier. Quite clever. I was mostly its assistant.

It also changed some of my assumptions. I thought software engineering was orderly and followed conventions, and that after 100 apps there would be few rules left to add, since the conventions of mainstream apps should be enumerable. The further I went, the clearer it became that this was wrong. Many leftovers cannot be found by any general rule, and some bundle IDs are not even reverse domain names. A convention that looks tidy may just be what some programmer typed years ago, with no theory behind it, so the only way is to install one and check one.

That first round of more than 300 apps gave Mole 13 kinds of reusable general rules and more than 90 precise cleanup paths. Along the way it also fixed more than 30 places I had thought should be cleaned but should actually be left alone, and added more than 100 unit tests. Those places to leave alone were as valuable to me as the new leftovers: a cache can be rebuilt, the user's own files cannot, and data several apps share should never go just because one of them was uninstalled.

I also wrote up the leftover paths and uninstall steps for every app as guides in Chinese and English on the site. All 850 are free to read, so even without any tools you can follow them by hand. See whether the apps on your Mac are in this list.

You only know an AI tool once you have used it

Before Mole had AI cleanup, many people had asked to clean up the data AI tools leave behind. I used to see AI coding session history as a valuable asset, so Mole only cleaned real caches and old versions there.

But using AI every day, I had piled up plenty of old artifacts, old sessions and worktrees I no longer needed, and one user's single opencode.db had grown to 62 GB and they urgently asked how to clean it. So I tested more than 30 AI tools one by one: 13 desktop apps, 13 command line tools, plus the folders OpenClaw, Hermes and Pi leave behind after uninstall.

Unlike the earlier install-and-uninstall rounds, this time I signed in to every tool I could and really used it once in a real project: asking questions, running agents, building code indexes, setting scheduled tasks. A lot of the data only appears after real use, and an app you install but never open will not show it.

For each tool, the AI compared against the state before install, measured what it wrote into the home folder, ~/Library, /usr/local/bin and the shell configuration, and recorded it in a ledger. Then it checked how many processes and how much memory the tool used, uninstalled it with Mole, and scanned the whole home folder by name for anything unlisted. Whatever was missing went into the code that night and was tested again.

This round was more surprising than ordinary apps. The most visible part was memory: the 13 desktop apps open together took about 23 GB, and one tool from a big Chinese company started 41 processes and 4.49 GB of memory on launch. Most of these tools are built on VS Code or Electron, so each window brings a string of helpers. That is why, when I built status monitoring, I gave each app one row and added up all of its child processes; in Activity Monitor alone it is hard to see who is actually eating the memory.

Then there were the small changes they made to the system. Some tools, on first launch, put a root-owned command link in /usr/local/bin, which becomes a dead link once the app is deleted. One put a python3.12 into ~/.local/bin, so typing python3.12 in the terminal afterwards ran its bundled copy. The worst was a Chinese command line tool: I ran it once, it told me it was no longer maintained, and then, without asking, downloaded and installed its new version, edited .zshrc, and renamed the old command to legacy.

The sizes were wild too. One desktop app downloaded a roughly 1 GB toolkit the first time I used its Work mode, 3.1 GB unpacked, carrying its own LibreOffice, FFmpeg and OpenJDK. My own ~/.codex, which I use every day, was already 24 GB, 17 GB of it sessions, and 12 GB of the Claude desktop app's 14 GB was the Cowork virtual machine. Many skill installers also write a skills/ folder into every agent's directory whether or not you have that agent, so I had config folders for Qwen Code, iFlow and Droid without ever using them. Mole's first version even treated them as 2.4 MB of tool leftovers and nearly cleaned out my installed skills as junk.

Something else I did not expect was processes. The morning after an uninstall, two command line tools had their folders deleted and grown back. The terminal sessions from the night before were still alive: the program files were already in the Trash, but the background processes kept writing logs into the folders. A command line tool has no window, and closing the terminal tab does not necessarily end it.

I also saw plenty of mess. Some installers quietly write something to your clipboard while downloading, to track the install channel. Some pop up endless prompts to join campaigns and claim tokens, ads plastered everywhere, the kind of tool you hold your nose to use. By comparison, Claude, Codex and Cursor stayed fairly restrained, and in China the one that pleasantly surprised me was Qoder: a clean interface, good taste, nothing pushy.

All this changed one of my earlier judgments. Sessions really are valuable, but old sessions and worktrees you are done with really do take space. Today's AI cleanup lists sessions by the retention period you choose, 15, 30, 90 or 120 days, each with its title and time, and keeps a recovery copy before deleting. A worktree only shows up when git can prove it has no uncommitted changes. opencode.db gets database compaction, which only returns the freed pages to the disk and never deletes the user's conversations.

System Data is the hardest part to test

A while ago I was browsing Reddit and saw many people complaining that System Data in macOS settings often reaches one or two hundred GB, asking what it is and whether it can be deleted. That number is only the result of a classification. Apple's own explanation also counts every file the other categories did not take, so it is not a list you can delete from. Mole's System Data group therefore only states how much it measured and can handle, and does not try to match the total in System Settings.

The hard part is that you cannot install one thing and check one thing on your own machine here. Every Mac's System Data is different, and many cases can only wait for a user report and then be traced layer by layer.

Take purgeable space. The number the system reports mixes iCloud files that can be reclaimed with caches the system will release on its own. Even a Mac with no local snapshots shows around 142 GB. Early Mole used that number to estimate how much snapshots could free, estimated 50.7 GB, and after cleaning the free space only grew by a few GB. Now the snapshot row no longer shows an estimated size; after cleaning, Mole measures how much free space actually changed, and since APFS does not return space all at once after a delete, it waits until the number stops growing. Along the way I caught a bug: reading free space always returned a stale cached value, so cleaning always showed 0 freed.

Another user's System Data held 179.53 GB of wallpaper render cache, 6644 files in all, an uncompressed BMP for every wallpaper at every screen size, never deleted by the system. The first version could find it but could not delete a single byte, because the wallpaper process is always running in the background, and the command that checks whether a file is in use reported errors on single files, which were treated as uncertain. In the end it only lists the ones older than a week that are not currently on screen, for the user to confirm, and this shipped in 1.17.

As for things like the 119 GB iPhone backup and the 79.5 GB Parallels virtual machine on my own Mac, they are big but should never sit behind a select-all delete button. Mole only shows their size and where to manage them, they cannot be ticked, and they do not count toward the space that can be cleaned, so people go back to the right place and make sure before doing anything.

Resending 400 emails, plus a small piece of magic

Over the National Day holiday I spent a day on something I had put off for a long time. I went through every Mole order from the May launch to the end of September that was bought but never activated, about 400, had AI write a simple local script to list the emails and keys, and resent them one by one, grouped by purchase month, country and language. Not a promotion, and not a push to activate, more like sending a message to a friend: a reminder not to forget it, and no rush if they are not using it yet.

Interestingly, replies kept coming in from users in many countries, and they meant much more than I expected. Some said they bought it just to support the development and actually preferred the Terminal version, and some had forgotten about the GUI and had been using the CLI all along. One user had bought two, one for themselves and one for family as a Christmas present, so it was still unactivated, the key already saved in their password manager. It made the world feel like a lovely place.

One user could use it on a work computer at first, until the company banned software outside its approved list, and was waiting for a new Mac of their own to start using it. Another bought during a discount and still had no MacBook, planning to activate as soon as the new machine arrived. Someone replied with just "Prefect!", and someone else said during the holiday that it was time to slack off properly, a pun on mole that only works in Chinese. These replies were a joy to read.

Quite a few, though, had simply typed their email wrong, probably in a hurry, gmai.com, gmail.con, cloud.com and so on, and never came to me. Others never got the first email and bought again to start using it sooner.

In the back-end data, all of these people have the same status: not activated. Sending everyone the same activation reminder would have meant getting the problem wrong. People who bought to support Mole, kept it as a gift or were waiting for a new computer had nothing to be reminded about; the ones with a mistyped email or a lost message were the ones who never got their key. The dashboard numbers cannot tell these cases apart. Only reading the replies one by one can.

So I filled in a piece of the post-purchase flow: after payment, the user is taken back to the site, which displays the Key right away, so even with a mistyped email or a blocked message they see it immediately. There is also a neat little detail: clicking activate on the web page invokes the installed client through a custom protocol and automatically fills in the Key, leaving the user to just press confirm without copying and pasting.

Taken apart, this small piece of magic is just the web page handing the system a link Mole recognizes, the system handing it to the app, and the app only placing the key in the input field. It never confirms the activation for the user; it still goes through the original license check, and the last step stays with the user. An engineer who has built clients or front ends may find this trivial, but to most users it feels like wow, how did it do that, this product did a little extra for me. Maybe that is what I keep chasing in products: a few fun touches that give users that sense of magic, a little of the hackers and painters feeling.

Lately I have been doing something similar: writing to the early users who bought Mole right after its launch in May, with versions in Simplified Chinese, Traditional Chinese, English, Spanish and French. The letter mostly thanks them for supporting it so early, mentions that the Mac version has added System Data and AI cleanup these months and that checking for updates in Mole brings them in, and ends by asking them to reply directly with anything that feels off or any feature they want.

Even a short letter like that went through several drafts. The first few always read a bit like a sales pitch, like a marketing email. I rewrote it line by line in the tone I use with friends, simple, clear, not wordy, until it read like a letter I would actually send myself.

Paul Graham wrote in Do Things that Don't Scale that Wufoo sent handwritten thank-you notes to early users and that the Stripe founders would take a user's laptop and set them up on the spot. Now that code is hardly a moat anymore, this kind of unscalable, patient work is worth even more.

A new set of icons, another round of copy

The detail that took the most time these two months was replacing every icon in Mole. Before, I used system icons, which are fine for simple cases but lack a bit of soul up close. After looking around, Remix Icon, which I use a lot for the web, did not look right in an app. I settled on Phosphor: about 70% could be used directly, and the other 30% I drew as SVGs with Opus 5.5 so the line width and style would stay consistent.

I have always wanted what I make to feel alive, with some spirit, so people using it can tell that care went into it, and small details like icons are a good place to start. For Keep Screen On I used a cup of coffee, a nod to Caffeine, as if the computer drank coffee and could not sleep. About usually gets a circled i, but I thought it should say hello, so I used a waving hand. Diagnostics would normally get a troubleshooting mark; I used a stethoscope, more like giving the computer a checkup.

Then the feedback after release made me realize some of the icons could still be better. Some icons I liked, users found unclear. Check for Updates used a download icon, so people read it as download. The little square for the GPU did not read as a graphics card, the archive icon was confusing, and two stacked memory sticks did not look much like memory. Some said the sponge for Clean Screen and the waving hand for About made no sense. Thinking about it, they were right: an icon first has to be understood, and looking nice comes second.

So I reworked all of these as people suggested. Check for Updates became a clockwise arrow, the GPU became a dual-fan graphics card, the archive became a storage box, audio went from a music note to headphones, Clean Screen went back to its original brush, memory went back to a chip, and About ended up as the most orthodox ⓘ, just redrawn to the line width of its column. Quite a few were changed three times before they finally felt right.

The copy took the same kind of fiddling. I had used up most of my Claude and Codex quota writing code, so I dug out Gemini, which had been gathering dust for a while, switched to 3.8 Flash High and asked it to look at the copy. It pleasantly surprised me: it may not be the very best at code, but it writes plain language very well. I put almost all of Mole's settings, cleanup item descriptions and site content through it. The brief was simple: talk like a person, simple, clear, easy to grasp, so someone using it for the first time gets it instantly, nothing stilted and no AI tone.

I had it output before and after versions with the reason for each change, then went through them one by one. It really felt like having a very patient language teacher sitting beside me, turning a lot of programmer-pleasing phrasing into words normal people can follow. For example, the cache deletion item used to be easy to misread as the way the whole app gets deleted; now it says clearly that it only covers ordinary caches on the Clean page and does not affect uninstall.

Accessibility helped a lot

Testing hundreds of apps brought an unexpected bonus. In its first few versions Mole already supported blind and low-vision users with many accessibility attributes, and this time they helped a lot: with them, the AI could find every button and element very precisely, and testing went much more smoothly.

Accessibility attributes give more than a coordinate. They say what a control is called, what kind it is and what state it is in, so when the interface shifts a little, a script still finds the same button. Relying only on screenshots and coordinates, a changed dialog or a moved window easily makes the click miss. From the start Apple wanted everyone to be able to use a computer equally, so much of the system can be read by VoiceOver, and I love that. Fellow indie developers, when you build apps and web pages, let your AI coding tool add accessibility along the way. Once blind users can really use it, it often comes back to help you in automated testing later.

One Mac, plus one ThinkPad

The Windows version was tested the same way, one app at a time. Windows was not starting from zero: Mole's Windows CLI has been maintained since early this year with contributions from the community, and the CLI is quite mature now. That groundwork is what made this desktop version possible. The desktop version uses native C# and WinUI 3 on Windows, and the Swift code of the Mac version is almost no use there. It took close to a month of back and forth, 78,000 lines of code and more than 4,000 test cases. The 486 Windows apps tested so far ran mostly in a Parallels virtual machine on the Mac. I also bought a ThinkPad X1 that stays on 24 hours a day, and the Mac connects to it through UU Remote and ssh, letting the AI operate this real computer directly for install, uninstall and cleanup acceptance.

Now my Mac is the main machine for all of development. It runs the Parallels virtual machine, connects to the ThinkPad X1 beside it, and has a small Android tablet on a cable; with adb debugging on, the AI can operate some services that have no API, and there is also the iPhone simulator in Xcode. All the AI context lives on this one Mac. Usually 7 to 10 terminal tabs of agents are running tasks, suggestions and feedback collected on social platforms go into Notion, and the AI marks them done once handled. That is how I can clear so many GitHub issues one by one on my own.

How exactly to build Windows software on a Mac, for example how to layer the code so the tests run on the Mac and how to drive the virtual machine with scripts, I wrote up separately in this post on Mole's blog, and the trade-offs in choosing the stack are in You Don't Know Client Development. Have a look if you are doing the same.

Polishing that looks like wasted effort

AI makes code faster to write and makes a passable interface much easier to build. It can look as if people have nothing left to do but talk. My experience these months is that the human part matters even more now, and the time AI saves us is exactly what we can spend on this polishing that looks like wasted effort.

Installing and uninstalling 850 apps one by one, reading every reply, redrawing dozens of icons three times: AI will not decide to do these for you. But once they are done, if 1% of your users now and then get that instant understanding, that wow, that feeling of a magic trick while using your product, it is very much worth it.

The pitfalls turned into cleanup rules, more than 100 new unit tests and public guides, so next time I do not start from scratch. That is what keeps this patient work from going to waste.

The more apps I test, the more I want Mole to keep its current restraint: no uploading of users' local files or session content, no usage analytics of any kind, and no new switch where a default will do.

Next on the Mac side I want to reach 1,000 apps first, and the Windows side will keep filling in too. If your computer has an app that is especially hard to uninstall or leaves deep leftovers, tell me in the GitHub discussion and I will put it on the next round's list. Steadily making a tool I enjoy using and others find reliable is what makes me happy.

The CLI remains open source and free on GitHub, and the desktop versions for Mac and Windows are at mole.fit. Feel free to come and complain anytime.

From Mole CLI to Mole for Mac: What I Learned

Tw93 — Tue, 08 Sep 2026 15:48:57 +0000

Lately I've piled up a lot of thoughts on indie development and wanted to pull them together, so this is the story of taking Mole from an open source CLI to a paid Mac app. What I was thinking at the time, and which parts actually turned out to matter.

Mole lives at mole.fit, and the CLI is open source on GitHub. Feel free to play with it first.

Last National Day holiday I sat by a pool in Sanya and wrote a few hundred lines of code. It became Mole CLI, a command line cleaner for the Mac, and I put it on GitHub mostly for myself and a few coworkers. Less than a year later it has 60K stars, 50-odd releases, code from 121 developers around the world, and nearly 800 feature requests and bugs closed.

I honestly had no sense of how many people were using it. Then one month two images I'd hosted on Vercel from the README blew past the bandwidth allowance and left me owing them 80 dollars. That was when it clicked that a desktop version was worth building.

The most common email I got came from users outside China, and they all said roughly the same thing. My parents use a Mac. So does my sister. Neither of them will open a terminal. Could you make a version they can just click? I sat on it for a long time, mostly because the CLI itself didn't feel finished. I only started on the desktop version after the CLI had run for most of a year and I knew what was safe to delete and how far to go, and I didn't ship it until I was using it every day myself. It shipped at ten at night. Notifications kept coming in through the small hours, payments from France, Germany and elsewhere, and I turned the email alerts off so I could sleep. I kept adding to it over the months that followed. A group of people paid first and then stayed around while I finished it. Nothing changed on the CLI side, it stays open source, free and updated, and the desktop app is the only paid part.

Three Kinds of Junk AI Leaves Behind

After the desktop version shipped, the feature I ended up using most was the cleaner, because my own Mac kept warning me it was running out of space. I have Claude Code and Codex running most of the day, and I noticed that the files AI leaves behind differ from what I used to find.

It's mostly three things. The most obvious is build output. You used to hand-write a few hundred lines a day and compile three or five times. Now you let an agent run a dozen rounds in an afternoon and every round compiles. Rust target directories, .next and dist on the front end, Xcode's DerivedData, they all grow fast. I once cleared 86GB in one go and it was entirely this. Second is old copies of the AI tools themselves. Claude Code and Cursor Agent self-update silently by downloading the whole new version, around 250MB each, and leave the old ones behind. After a few months there are a dozen versions sitting there. Then there are local model files pulled through Ollama or LM Studio, easily eating up tens of gigabytes.

Collapsing all of these into a single "safe to delete" list is certainly easier, but the cost is making high-risk decisions on the user's behalf. Now I handle this data based on what it costs to get it back. When a candidate is scanned, its ownership is determined before deciding whether it gets checked by default.

For build output, most logs, and HTTP and GPU caches, deleting them means recompiling or refreshing a page, and the price is a few minutes of CPU. As long as the owning app has quit, they can be checked by default. But node_modules, Pods and venv are different. They look like similar dependency directories, but deleting them means downloading them all over again, and on a plane or a train you're just stuck waiting. The two are easy to lump together. Mole CLI did exactly that early on, and later I pulled every download-only directory out of the Mac app's clean list. The user needs to look at those first.

Models are the heaviest thing in here, and redownloading tens of gigabytes takes a long time. A general purpose cleaner couldn't delete them correctly even if it wanted to. Ollama splits a model into hash-named blocks and several models can share the same block. Delete a large-looking block straight off the filesystem and you may well break a different model. Only the tool itself knows those relationships.

So ~/.ollama/models and ~/.cache/huggingface are hardcoded into a protected list. They never appear during a scan, they only show up in the disk analyzer as a size, and the models themselves stay under Ollama's and LM Studio's own management.

There's one thing even more off-limits than models, and that's AI chat history. ~/.codex/sessions, ~/.claude/projects and ~/.grok/sessions hold months of full conversations, sometimes a year. Your thinking at the time, the approaches you rejected, the reason behind every change. Delete it and it's gone, and in a way it's worth more than the code. Those paths can never be cleaned in Mole, no matter how long they've sat untouched, and the same protection covers memories, plans, skills and generated images.

None of that protected list was designed up front. It was mostly learned the hard way. The dumbest one was com.apple.e5rt.e5bundlecache. The name says Caches, it lives in the cache directory, everything about it reads as a cache, and it's actually where Apple's Neural Engine keeps compiled models. The CLI cleared it as a cache early on, and every app using recognition features broke for those users until they rebooted. Since then I run three questions in my head whenever I see a directory with cache in the name. Who writes it? Who reads it after a reboot? If I get this wrong, how do I get it back? If I can't answer one of them, I leave it alone.

Show It Before You Delete It

What I care about most in a tool like this isn't how much it can clear. It's whether it lets you see things first.

Mole scans, then lists every item with what it is, where it lives and how big it is. Anything uncertain is unchecked by default. You confirm, then it deletes, and it prefers the Trash so you can change your mind. Scanning and cleaning happen entirely on your machine, and no file or result leaves it. The cost is that it's slower, there's an extra step, and it feels fussy on the days you just want it done. I'd still rather it miss something than delete something it shouldn't.

Uninstall follows the same logic. Pick an app and Mole pulls up everything it has scattered around the system, each item labelled with its path and size. In the screenshot above Claude itself is 781MB while ~/Library/Application Support/claude is 7.67GB, which is usually the case: the app bundle is never the part taking up space. Login items and background services live on the same page, so you don't have to hunt through System Settings for them.

Take macOS update payloads, the /macOS Install Data directory. It's often more than ten gigabytes and it looks like a perfect thing to clear. But the system may still need it to finish installing, and removing it too early can leave the machine unable to boot. So it's a review-only item in Mole, unchecked by default, behind three gates. If there's a pending system update the row is hidden. If anything in the payload was written in the last 14 days it's hidden. If an installer process is still running it's hidden. If any of those signals can't be read, it's treated as risky and doesn't show at all.

At the moment of deletion the root helper runs all of those checks again and exits nonzero if any of them fails, so you don't end up with a report claiming it freed 12GB when it didn't touch a byte.

I have a crude way of judging any cleaner. Install two products from the same vendor, uninstall only one of them, and see whether the tool offers up the Application Support parent directory or the group container that both of them share. If it does, it's matching on names rather than reasoning about ownership. I'm not comfortable letting a tool batch-delete anything if it can't tell me who owns what.

It Doesn't Come Looking for You

It looks everywhere it should, it just doesn't come looking for you.

It won't pop up every few days to remind you it's time to clean, and it won't finish a scan and announce how much danger your computer is in. Open it when you want to clean something. The rest of the time it may as well not be installed.

The interface follows the same idea. The result page doesn't appear until the scan is done, a short wait shows no spinner at all and only a longer one brings up a working animation, and the completion screen reserves its space in advance so the window doesn't jump when the result lands. Each of these rules is small, and together they're why the app feels steady.

The work underneath is unpredictable by nature, and animation doesn't fix that. What fixes it is the flow itself being reliable. I don't want a maintenance tool that needs watching. I want to start a task, let it finish, then come back to the results without a blinking light constantly asking for my attention.

The same goes for accessibility. Reading order, keyboard operation, whether focus stays put, none of that is separate from how quiet the thing looks. With Reduce Motion turned on the planets stop their decorative spin and state changes move around less, and nothing you do depends on understanding an animation.

Building for Someone in Their Seventies

I used to build things thinking only about whether the people around me found them handy. Going from a CLI to a desktop app taught me that getting it usable for someone in their seventies takes a lot more, and it's a lot more interesting. Everything below came out of three months of user email, and it's where most of what I learned came from.

A British user in his late sixties wrote to say he'd had a senior moment and bought Mole twice. "Consider the second payment a gift. Thank you for this excellent tool, it has saved me far more pounds than CleanMyMac ever did." I suggested a refund, or giving the extra licence to someone. He asked around and wrote back the next day: "None of my neighbours use a Mac, and neither do my Bluesky followers. This round is on me." Getting a letter like that makes you feel you have to make the thing better to deserve it.

An American user corrected something I'd had backwards about regional habits. I'd assumed Americans wanted Fahrenheit, so that's what the US default was. He wrote: "Americans use Celsius in every technical context. Only weather and body temperature are Fahrenheit. I installed Mole, saw 110, and got a fright. Apple publishes US specs in Celsius, and fastfetch and neofetch both default to Celsius on American systems. Keep the Fahrenheit toggle, but default everyone to Celsius." It now defaults to Celsius with Fahrenheit available. He followed up about pricing too. The number I'd picked didn't read like a deliberate price, he said, more like something converted from another currency. Then he added: "When I say foreign I don't mean anti-China. People want to feel the author understands them." Honestly, that price was something I made up on the spot. I'd never thought seriously about pricing before selling anything, and having a stranger point it out was a bit embarrassing. It hadn't occurred to me that the price number itself shapes how people decide.

A user with mild vision impairment wrote: "Looks like a very nice app. Shame I can't use it, it seems to hardcode dark mode. My system is set to light and I only use light mode apps." Mole being dark-only was a deliberate call. The menu bar panel floats over the wallpaper like a HUD, dark glass glares less, and it saved adding a theme switch. But that reasoning doesn't hold for him. I'd been telling myself I took accessibility seriously here, and it never occurred to me that light mode is itself an accessibility need. That email arrived a while ago. Mole is still dark-only and light mode is still sitting on the list. A product that claims to care about accessibility has left someone who told me plainly that he can't use it waiting this long, and that one bothers me.

A lecturer at a German university wrote asking about an educational licence, describing it as "not only support for me personally, but a meaningful kind of support at the educational level." I had no idea teachers were using this in a classroom setting. A doctor in Hungary left the most honest bad review I've had: "To be blunt, this is a little expensive for something a free app can also do." That one doesn't sting at all. Purchasing power varies enormously between countries, and he wasn't complaining, he was helping me locate a problem.

My favourite features in Mole didn't originate with me. The low battery alert for AirPods came out of the battery health work, and I never hit the case myself until one afternoon it actually fired, which felt thoughtful without being noisy. Keep Screen On grew three different behaviours after a user pointed out what was missing. Now if I head out on a weekend the AI coding session keeps running, which has saved me a lot of waiting. Seeing the iPhone's battery level in the status view was hard to implement for a while, and eventually there was a way. Users told me to build all of these, and I'm the one who got the most out of them.

I Still Answer Every Email Myself

Support questions, refunds and licence resets add up to well under 1% of users. Half an hour of scripting would automate all of it, and I haven't written that script. Handling them one at a time is the only way to feel what people actually want, why they refunded, and where the thing made them uncomfortable. That's usually not what they asked in the first sentence. My bar for automating is three things holding at once: the question keeps coming up, the answer is stable, and I understand the exceptions. Until then I'd rather answer each one myself. It still works, I've spent nothing on marketing, growth is mostly word of mouth, and refunds are under 0.8%. A good number of buyers were long-time CLI users first.

I also didn't build a ticketing system, a support platform or a knowledge base before launch. Engineers like standing up the support machinery first because it's familiar work, and AI compressing it into half a day makes it even easier to start too early. Building it takes half a day, maintaining it is long-term work, and nobody needs it yet. The day the inbox starts dropping requests, or response times get murky, or the same question gets two different answers, that's when a new system is actually needed. AI shrinks the building time to a few days, but talking to people isn't something you can hand off, or making a product stops being interesting. Handling every email yourself is how the trust builds up.

A Few Things That Actually Helped

Writing code is actually a small part of it. The real time goes into figuring out where the pain actually is, how to make it usable without a manual, and how to get it in front of the right people. Doing every step yourself feels very different from just writing code.

For a cleaner, what you don't delete matters far more than what you do, which is where those protected lists came from. A lot of feature ideas are perfectly good, but if they don't fit what Mole is for, I keep them out. Otherwise it turns into a pile and becomes a nightmare to maintain.

You need a rough roadmap in your head so you know which requests to turn down. If a piece of software needs no manual for people to pick it up, it passes. I've declined plenty of nice suggestions the moment they threatened to make the app louder or more complex. If one Mac user in a hundred finds it useful, that's enough.

A feature has to pass three gates before it reaches the roadmap now. No always-on timers, listeners or sampling cost while the user isn't in that feature. No expanding the privileged helper or adding a system permission for a small convenience. No new setting when a sensible default exists. That isn't a universal principle for all software, it's a rule Mole set for itself. Every extra bit of always-on work, privilege and configuration is one more thing users have to trust you with.

I've never saved up for a big release. I aim to ship something every week, which keeps user problems moving and keeps the back and forth going. Every release, update and announcement is a good excuse to talk to people, and it gives anyone who missed the earlier ones a way to find out what you're doing.

Now that AI writes code, the time it saves is exactly what you should spend figuring out what people need. Things like talking a problem through, looking properly at the data, or writing copy that makes sense on the first read. I don't mind spending tokens, as long as they make a difference users can feel.

Mole has been global since day one, and I publish more in English than in Chinese. What struck me is how large the world is and how far users are spread, and that they're willing to trust you from the start. People you helped in passing often become your users later, because there was something real between you. I've never paid for promotion either. Posts on X get a burst of attention that fades quickly, whereas things posted to YouTube keep getting views for much longer, and if the thing is good and someone recommends it, it stays alive there for a long time.

I spent a fair amount of time looking at the data. Putting sales, traffic, comments, refund reasons and GitHub issues side by side surfaces plenty of blind spots I wouldn't have seen, and shows exactly where people walk away.

The last one is mindset. Chasing follower counts just to sell things makes you anxious. Posting the real process, the mistakes and the updates shows people you're actually building something, and trust follows naturally. With so much over-promised noise around right now, nobody pays attention if they don't trust you. Staying honest and playing the long game gets you much further.

Why Five Planets

Mole for Mac is five parts: Clean, Apps, Optimize, Analyze and Status. Each one has a planet in the interface. Clean is Earth, Apps is Mars, Optimize is Mercury, Analyze is Jupiter, Status is the Sun. It comes from liking planetary motion as a kid, and from WebGL being the first thing I badly wanted to learn after picking up front end work ten years ago. The two happened to meet. I swapped the planet textures more than ten times and pulled a lot of them from NASA before settling. The spin direction, the rotation speed and the flight at the end all follow how the real bodies behave.

None of this had to exist. A menu bar item with a clean button would have worked. But there's more than enough AI-generated cyber junk already, and rather than spend tokens stacking up another interface that merely runs, I'd rather make something pleasant. It doesn't waste my tokens and it doesn't pollute your timeline.

I like things arriving in their own time, and I try not to rush the schedule. That's only been reinforced these past three months. Building something I enjoy using and others are willing to pay for is already a great place to be.

The CLI is free and open source on GitHub, and the Mac app is at mole.fit.

This is my first time selling something, so there are definitely things I missed, and I welcome any advice. Looking back, the changes that shaped this most all came from someone's email or an issue. Listening to people complain has honestly been the biggest help.