Privacy-first local tool suite: 87 tools, zero uploads
The problem
I was trying to use online document editors to do some routine work on a confidential document, and kept hitting the same wall: there was no way to do standard document tasks without sending the file off to an untrusted server first. On top of that, most of these tools wanted an expensive subscription just to complete one or two small tasks.
The opportunity
I wanted to fix that specific problem: a privacy-first toolbox that could do all of this entirely on a user's own machine, without a document ever touching anyone else's server.
The solution
What started as a plan for a handful of tools has grown into something much bigger: 87 tools so far, covering PDF, image, dev and text utilities, every one running entirely client-side via WebAssembly, so a file never leaves the device. A £6/mo Pro tier sits around it, with real auth, billing and growth mechanics built out.
Technical challenges
Making sure a customer who tries to pay for Pro genuinely can, which meant testing against a real payment session end-to-end rather than trusting that the code looked right on paper.
Making sure cancelling actually cancels everywhere it needs to, not just in the app's own records, since anything out of sync with the payment provider risks continuing to bill a customer who thinks they've already cancelled.
Making sure access updates the moment someone cancels, not weeks later, which meant checking a live, authoritative record on every visit instead of trusting an old browser session.
Making sure the sign-up flow can't quietly break at the last step, since a failure right after a successful payment could leave a paying customer permanently locked out.
Making sure free-tier limits are enforced server-side, not just displayed on screen, so what a user sees always matches what's actually being allowed.
A privacy-first grammar and word-checker tool, built as an additional tool rather than a headline feature. It works well technically on its own, and the current work is figuring out how best to integrate it into the final release rather than bolt it on separately.
Lessons learned
Every one of those risks would have shipped invisibly. They only surface when you test against live infrastructure rather than trusting that the code looks right. That's the standard I hold this kind of work to now: audit it like a customer would try to break it, not like a reviewer would read it.
Current status
In its final stages: finishing the remaining tools and going through last checks and audits before public launch.