I'm Theodore Harding. I write software from a desk in the UK, mostly alone, mostly for Mac. Shiny is a $4.99 menu-bar app that frees memory with one click. It is the first app I have shipped properly: notarized, paid, supported, and documented. You can read why I built it here.
This post is aimed at other developers who are thinking about shipping something small. Not a startup, not a SaaS, not a VC-backed product. A small Mac utility, sold honestly, maintained by one person. The things I wish I had read before I started.
The technical reality: notarization, Sparkle, and the things you only learn by shipping
The code for Shiny is not complicated. It calls a macOS API to pressure memory, closes orphaned helper processes, and sits in the menu bar. Any intermediate Swift developer could write the core in a weekend.
The surrounding infrastructure is where the surprises are.
Apple Developer ID and notarization. You cannot distribute outside the App Store without a Developer ID certificate, and you cannot ship that certificate's output without notarization: Apple scanning your binary and stapling a ticket so Gatekeeper lets it run. The first time you hit it you will probably spend a day on entitlements plists or notarytool polling. Apple's Developer ID overview is the right starting point, not Stack Overflow answers from 2019.
Sparkle for updates. Direct distribution means you need an update mechanism. Sparkle is the standard: an appcast XML file, EdDSA signatures on every package, careful version string discipline. The part nobody mentions: your first update will probably fail because the signature was generated against the wrong binary or the appcast URL was wrong in Info.plist. Ship a test update to yourself before you ship to anyone paying.
The things you only learn by shipping. Gatekeeper is aggressive about quarantine attributes. Users downloading from a browser still see the "are you sure" dialog even after notarization, because the quarantine xattr is set at download. Right-click-open solves it, but it will generate support emails and some users will assume the app is dangerous. Plan for it in your onboarding copy. Brent Simmons has written honestly about the realities of independent Mac development for years; his writing is worth reading before you start.
Payments: why I chose Polar over Stripe and what UK VAT actually means
When I started thinking about payments, Stripe was the obvious default. Everyone uses Stripe. The documentation is excellent. The developer experience is genuinely good.
I chose Polar instead, for one reason: they are a merchant of record.
What merchant of record means in practice. Selling software in the EU means collecting and remitting VAT in each customer's country. The EU One Stop Shop scheme simplifies remittance to a single quarterly return, but you still have to register for it. Stripe does not do that for you. A merchant of record like Polar does. You receive net payouts; the ledger is their problem.
UK VAT specifically. Post-Brexit, UK developers are outside the EU OSS scheme. The UK registration threshold is currently £90,000 turnover: below it, no UK VAT registration needed. But EU customers still trigger EU VAT obligations regardless. If you are early-stage, a merchant of record lets you sell globally without setting up VAT in each jurisdiction.
Apple's IAP. The Mac App Store handles all tax globally and is its own merchant of record. The cost is 30% commission and sandboxing. Shiny needs entitlements the sandbox does not allow. For an app with no elevated system access requirements, the App Store's tax simplicity is genuinely compelling.
Marketing: the calm-software niche, saying "you may not need this" out loud, and how to post on Reddit
Most Mac utilities market themselves with urgency. Your Mac is slow. Your Mac is at risk. Act now. This is effective, in the same way that a fire alarm is effective: it produces action through anxiety.
I did not want to do that. Shiny's pricing philosophy is grounded in honesty: it is a $4.99 tool that does one thing, and some people do not need it. Saying that out loud, in the marketing, turned out to be a differentiator.
The calm-software niche. There is a small but real audience for software that does not shout. Apps like Tot, Reeder, and Quill have demonstrated that calm, focused, one-job tools can find paying users. The marketing for these apps tends to be quiet, factual, and direct. Copying that register was a deliberate choice for Shiny, not a default.
Saying "you may not need this." On the Shiny website, I wrote plainly that if your memory pressure stays green, you probably do not need Shiny. This is true. It is also the kind of honest statement that builds the trust required for someone to hand over $4.99 without a trial. Several users have told me they bought it partly because the marketing did not oversell. Counterintuitive, but it works.
Reddit and Hacker News. Post where you are a legitimate member, not just a marketer. On Reddit, add value in comments before you link to anything you built, and be honest in the post title: "I built a small Mac memory cleaner, here is how it works" outperforms "This app will save your Mac." On Hacker News, "Show HN" posts work when the product is genuinely interesting to developers. A $4.99 no-telemetry utility with an honest origin story plays better than feature bullets.
The decisions I almost got wrong
Three decisions I nearly made differently, and what stopped me.
Subscription pricing. The standard advice in indie SaaS circles is: subscriptions are more predictable, and predictable revenue is better. That is true for SaaS. It is not obviously true for a static utility. Shiny does not add features month to month. Memory clearing works the same this year as next year. Charging $2.99 a month for a tool that does not change would have felt dishonest, and I think users would have felt it too. I went with $4.99 once. Early evidence suggests the one-time price converts better at the small scale I am operating at, because there is no commitment anxiety.
Telemetry. I considered adding analytics: how many times a day do people click the button, which menu items do they use, what does session length look like. I decided against it. See no-telemetry-explained for the full reasoning, but the short version: the value of that data did not outweigh the cost of the trust required to collect it. At $4.99, users are paying a small price for a simple tool. Loading it with analytics felt like a bad trade on their behalf.
Scope creep. After the initial release I had a list of features users had asked for: disk cleaning, login item management, a usage history graph, scheduled cleans. I added none of them. Each one would have made Shiny bigger without making it better at its actual job. The discipline of staying at one job is harder than it sounds when you have a product that is shipping and users who are asking. It helps to write down why the app exists before you start taking feature requests.
The job nobody talks about: customer support for non-technical Mac owners
I expected the support emails to be from developers with edge cases. They are mostly from non-technical users who are not sure what they bought, or are not sure it is working, or want to know whether they need to reboot after using it.
What email volume actually looks like. At Shiny's current scale, roughly two to four support emails arrive per week. Most are straightforward: licence key not arriving (check spam), app not opening (quarantine attribute, right-click to open), question about whether three Macs means three licences (no, one licence, three activations). A few are more involved: an older macOS version, a double purchase, a genuine edge case.
The register that works. Non-technical users need replies that are short and plain, with no assumed knowledge of terminal paths. "Open System Settings, go to Privacy and Security, scroll to the bottom" works better than "navigate to /Library/..." Every support email is also a product signal: if the same question comes up three times, the answer belongs in the FAQ, not just individual replies.
The emotional reality. Some users are frustrated when they write. Replying calmly, quickly, and without defensiveness is the job. For a $4.99 product, offering a refund before the user asks for it is almost always correct. It costs $4.99 and buys the most important asset a small indie has: the feeling that there is a real person on the other end.
That is the honest summary. The code was the easy part. The paperwork, the VAT scheme, the pricing call, the scope discipline, the support emails from people who are not sure what memory pressure means: those are the job. Most of them are invisible to users, which is exactly as it should be.