Notes on Building a Quiet Product

Mole for Mac passed a small sales milestone about three weeks after launch. Instead of writing about the numbers, I want to write down a few choices I made along the way, because most of them run against the instincts of a working engineer, and they are the choices I would defend first. If you are building your own product, maybe some of this saves you a detour.

I answer every email myself

Every piece of support since launch has been handled by hand: refunds, activation resets, refunding a price difference after a discount, ordinary questions. The volume is small, well under one percent of users ever write in, and I could have wired up an agent to handle it in half an hour. I chose not to, for two reasons.

First, support is where the product tells you the truth. A refund request tells you why the product disappointed someone. An awkward question tells you which part of the app fails to explain itself. A few emails back and forth surface what a user actually wanted, which is often not the thing they first asked for. Filter that through automation on day one and you lose the signal exactly when you need it most.

Second, handling every case makes you fluent. After enough rounds you know the best answer to each class of problem, and you know which problems the product should absorb so the question never gets asked again. When the volume grows and I do bring in automation, it will encode that fluency instead of guesswork.

So far the approach holds up: I have spent nothing on marketing, growth is word of mouth, and the refund rate is under 0.8 percent.

The scaffolding can wait

The same logic applies to infrastructure. I did not set up a ticket system, a help desk, or a knowledge base before launch. Engineers love building the supporting machinery first because it is the part they know how to build, and AI has made it a half-day job, which makes it more tempting and just as wrong. The half day is real; so is the ongoing cost of tending a system you did not need yet. All of it comes out of the same budget, which is the time you have to make the product itself better.

Deciding what not to build

The difference between a good product and an average one is mostly the things it declines to do. Which features belong in which release, which requests are real needs and which only sound like them, which genuinely good ideas still do not belong in this product. I have apologized to users who suggested features that were good on their own terms, because a Mac has plenty of nice tricks that Mole should not perform. Say yes to everything and you get a stew, and a stew is hard to maintain and harder to trust with deleting files.

I keep roughly half a year of the product's path in my head: what each version adds, what stays out, and where things land so that a first-time user finds them without instructions. A product that needs a manual has already failed the people I most want to reach. The old razor says it best: do not add an entity unless it is necessary.

A product decision loop where direct conversation preserves user context until a recurring need passes product fit, trust and safety, and self-explanation gates before it is fixed, scheduled, or declined; early automation loses the signal
Direct conversations preserve context until a recurring need becomes clear. Product fit, trust, and self-explanation decide whether it becomes a fix, a roadmap item, or a deliberate no. A good fix leaves fewer future questions.

The position

Mole's position is one sentence: a quiet keeper for your Mac. It cleans, uninstalls, optimizes, analyzes, and watches, and otherwise stays out of the way. The ambition is simple to state: if one of every hundred Mac users keeps Mole around, it will have become genuinely useful. Recently some visually impaired users started using it and ran into rough edges, so accessibility fixes moved ahead of new features. I am looking forward to how the app feels for them; a quiet keeper should be quiet for everyone.

Keeping products human in the AI era

AI made much of this product possible. It did not replace talking to the people who use it, and I do not think it should. Efficiency is easy to buy now; the feeling and trust between a developer and their users still has to be earned one conversation at a time. Perhaps that is how products built with AI keep their human warmth: the code can be generated, the relationship cannot.

This is my first paid product, and some of these calls may turn out to be wrong. If you have walked this road longer than I have and see me doing something foolish, I would like to hear it. How Mole got here in the first place is a longer story, told in From a 500-Line Shell Script to a Mac App.