The specific moment: a user opens Affinity Photo, sees a notification that there's a new version, and then discovers — as multiple users have noted explicitly — that there is no auto-update; they have to download the full installer again, find it in their downloads folder, and run it manually. This happens every single time. For a tool they use daily, that friction compounds fast.
This gap persists because standalone apps sold outside a subscription model (like Affinity, sold as a one-time purchase) have less commercial pressure to build polished update infrastructure. The engineering investment in a robust auto-updater — delta patching, background downloads, silent installs, rollback support — is not trivial, and a small team that has already shipped the app often deprioritizes it. The result is exactly what users are complaining about: download the installer again each time.
What's needed is an embeddable auto-update library that indie and mid-size creative software developers can drop into their app with minimal integration work. It handles background version checking, delta downloads (so users aren't re-downloading a 500MB installer for a 2MB patch), staged rollouts so a bad release doesn't hit all users simultaneously, and a simple rollback mechanism. The developer configures it via a hosted dashboard, sets rollout percentages, writes release notes, and monitors adoption and crash rates post-update.
This is a business because the problem recurs with every release the developer ships, the developer is the buyer (not the end user), and the alternative — building this in-house — costs a small team weeks of engineering time that they would rather spend on features. The end user pain is real and visible in reviews, which gives developers a direct revenue-protecting reason to care: bad update UX shows up as one-star reviews.
What to build
Build an embeddable SDK for Mac and Windows desktop apps that handles background delta updates, staged rollouts by percentage, and one-click rollback, plus a hosted developer dashboard for publishing releases and monitoring post-update crash rates — packaged so a solo developer can integrate it in under a day.
Where to start
Target developers already distributing on the Paddle or Gumroad storefronts, where there is no built-in update mechanism at all, and where developers are already paying for third-party tooling — making them a warm audience for another focused infrastructure purchase.
The hard part
The hardest early problem is convincing a developer to embed a third-party SDK into their shipping binary — there is legitimate concern about supply chain risk, so you need either a strong open-source trust story or a way to let developers self-host the update server while still paying for the dashboard.
How it makes money
Monthly fee per app published, tiered by number of active installs, with a free tier up to 500 installs to get embedded in early-stage projects before they scale.
See the evidence. The complaints behind this idea, the products they came from, and similar ideas in Photo Editing.
More ideas in Photo Editing