# What Mac Users Taught Me About Building Trustworthy Software > A temperature default, an inaccessible dark interface, a duplicate purchase, and blunt pricing feedback changed how I think about trust, localization, accessibility, and support. Published: 2026-08-16 When Mole moved from a shell command into a Mac app, I expected the difficult part to be the interface. The surprising work was unlearning my own assumptions. A person bought the app twice by mistake and declined my offer to refund the second purchase. Another corrected the temperature unit I had chosen for their region. Someone else could not use the app at all because its dark interface was hard for them to read. A blunt price objection made me reconsider what a paid app must earn when free tools already exist. None of these arrived as a tidy feature request. Each conversation exposed a different gap between the person I imagined and the person actually using the product. That gap has taught me more than another comparison table or analytics chart could. ## Trust is part of the feature The duplicate purchase stayed with me because the practical answer was simple: I could return the money. What made it difficult was the trust behind the mistake. The person had already paid once, made an error, and still wanted the second purchase to support the work. That is generous, but it also creates an obligation to make the product easier to understand and safer to use. A utility that deletes files has a larger trust gap than most software. It asks someone to believe that a scan has attributed files correctly, that an uncertain item will not be selected, and that a mistake can be recovered. A polished screen cannot carry that promise by itself. The product has to show the plan, explain why something was skipped, protect shared data, and use the Trash when recovery matters. Those details are not support work around the feature. They are the feature. This changed how I read praise as well. A compliment is pleasant, but the useful question is what the person trusted the product to do. If the answer is “remove files without making me anxious,” the next release should strengthen review and recovery before it adds another category to the scan. ## Locale is not a preference profile I once assumed a US-localized Mac should display hardware temperatures in Fahrenheit. A user explained that technical temperatures are normally read in Celsius even when weather and body temperature use Fahrenheit. Seeing a chip at 110 degrees without the expected unit felt alarming rather than familiar. Mole now defaults hardware temperatures to Celsius in every region and keeps Fahrenheit as an explicit choice. The code change was small. The correction behind it was larger: a locale tells me how to format language, dates, and numbers. It does not tell me how someone understands every technical domain. The safer product rule is to begin with the convention of the thing being measured, verify it with people who use that convention, and preserve an explicit choice when both forms are useful. Automatically guessing more preferences from a country can feel personalized while making the product less familiar. ## Accessibility begins with “I cannot use this” Mole has invested in VoiceOver labels, focus order, reduced motion, and increased contrast. I had started to think of accessibility as a body of work the product already took seriously. Then a person with low vision explained that white text on the fixed dark interface was difficult to read and that they used only apps which followed the system's light appearance. That feedback changed the category of the problem. Light appearance was no longer an aesthetic preference or a request for another setting. For this person, it was the difference between using the app and leaving it installed. Mole still forces a dark appearance today, so this remains a real gap rather than a finished success story. Accessibility is not a badge that becomes true after enough labels are added. A product can work well with VoiceOver and still exclude someone through contrast, color, motion, target size, or an appearance decision. The useful question is not whether the app “supports accessibility.” It is which task a person still cannot complete, under which system settings, and what part of the interface prevents it. ## A price objection can be product research One user told me plainly that the price felt high for work a free app could do. The easy reactions would be to defend the price, lower it, or add features until a comparison table looked longer. None would answer the important part of the message. Free tools really can solve many Mac maintenance jobs. The open-source Mole CLI remains free, and macOS already includes Activity Monitor, Storage settings, Finder, and the Trash. A paid app has to earn its place by making repeated work safer, bringing scattered information together, and helping someone who will never open Terminal understand what will happen before it happens. If a free tool already solves a person's job, recommending it is more honest than inventing a reason to sell them another app. The objection therefore became a positioning test, not a prompt to expand the product. It asks who benefits enough from the native app to pay for it, what they would otherwise have to assemble, and whether the difference is visible during a trial. If those answers are weak, marketing cannot repair them. ## Turn the story into a changed assumption Feedback becomes noisy when every message enters the backlog as written. One person asks for a switch, another asks for a lower price, and a third describes a mistake that may never happen again. Treating all three as feature votes loses the context that made them useful.
A feedback path that starts with the user's blocked task, identifies the product assumption that failed, tests whether the issue belongs to the product, then ends in a changed default, a targeted fix, or a deliberate decline rather than placing every request directly into a backlog
A useful conversation changes the product's model of the user before it changes the roadmap. The outcome may be a new default, a focused fix, or a clearer reason to decline.
I now try to carry four facts out of a conversation. What was the person trying to do? What assumption in the product failed? Does the failure affect a class of people or only this one setup? Can a better default solve it, does it need a focused fix, or should the product explain why it will not take the request? This is slower than counting requests, but it creates fewer settings and fewer half-solutions. The Celsius conversation changed a default. The appearance conversation exposed unfinished accessibility work. The price objection clarified the boundary between the free CLI and the paid app. The duplicate purchase did not need a feature at all; it reinforced the standard of care expected from a product trusted with personal files. ## Keep the conversation long enough I still handle support directly because early conversations are usually too messy to summarize on the first reply. The initial question may be about a license while the real problem is confusing device language. A refund request may reveal an unclear promise in the product page. A request for a setting may be evidence that the default is wrong for everyone. Automation becomes useful after the question repeats, the answer stays stable, and the exceptions are understood. Before that point, shortening the conversation can remove the exact detail that would have improved the product. I wrote more about that boundary in [Notes on Building a Quiet Product](https://mole.fit/blog/notes-on-building-a-quiet-product). I am still getting some of these calls wrong. The temperature default was corrected; the fixed dark appearance has not been. Some feedback becomes code, some becomes a product boundary, and some remains an open obligation. The valuable part is not saying yes to every person. It is leaving each conversation with a more accurate idea of who is using the product and what they need to trust it. The longer path from a private script to this app is in [How Mole Grew from Shell Script to Mac App](https://mole.fit/blog/the-story-of-mole), and the safety choices behind review-first deletion are covered in [Designing Mole to Stay Out of the Way](https://mole.fit/blog/the-design-of-mole). --- Canonical HTML page: https://mole.fit/blog/what-mac-users-taught-me Blog index for agents: https://mole.fit/blog/llms.txt Site index for agents: https://mole.fit/llms.txt