My first instinct was to say yes. Someone had paid for the app, taken the time to write, and asked for something that sounded completely reasonable. Saying no to a paying customer feels rude in a way that saying no to your own idea never does. It is the easiest yes in the world, and that is exactly why it needs checking rather than trusting.
What the request is actually a proxy for
Nobody wants an account. What they want is to not lose forty minutes of thinking because they dropped their phone in a lake, or upgraded to a new one and forgot to check something first. "Add accounts" was the solution they reached for, not the problem they had. If I had built exactly what was asked, I would have added a login screen, a password reset flow, a server, and a reason for people to worry about a data breach, on an app whose entire pitch is that nothing leaves the device. All to solve "I am worried about losing this."
The fix for the actual problem turned out to be smaller: a one tap export to a PDF a person can save wherever they already trust, Files, iCloud, email to themselves. It took three days instead of the three weeks an account system would have needed, and it solves the fear without touching the promise that made someone choose Appray over a note taking app with sync built in.
This is the part that took me longest to learn. When someone hands you a solution, thank them and then set it aside. Keep the sentence they said right before it, the one describing what actually went wrong for them.
Would this still make sense if only one person ever asked?
The second thing I check now is whether the request survives being rare. Two emails in a week is not a trend, it is two people. So I ask myself: if nobody else ever brings this up again, was building it still the right call, or was I about to redesign the product around a sample size of two?
Export passed that test easily, because losing your work is a fear anyone can have regardless of how many people mention it, and the fix cost three days. An account system would not have passed it. Three weeks of infrastructure, an ongoing maintenance cost, and a permanent change to what I can honestly say about privacy, all justified by two emails, is a bad trade even if twenty more people eventually asked for the same thing.
The one I built anyway, in an afternoon
Not every request needs this much scrutiny. Someone asked, in the same month, whether they could duplicate a finished Appray session as the starting point for a new one, instead of answering all eight rounds again from scratch when testing a variant of an idea they had already run once. That one I just built. It cost an afternoon, it did not touch the architecture, and it was obviously useful the moment I imagined using it myself, which I have, four or five times since.
The size of the ask matters as much as the reasoning behind it. A cheap, reversible feature that clearly helps does not need the full test. Save the scrutiny for anything expensive, hard to undo, or that changes what the product promises.
The one I said yes to too quickly
Six months before any of this, someone asked for a way to tag old sessions by project name, because they were running Appray for three different ideas at once and the history screen was a flat list. I built it in a week, and it was the wrong week to spend, not because tagging is a bad idea but because at the time exactly one person had more than two sessions saved. I designed a small taxonomy around a problem that thirty other users did not have yet.
Eighteen months on, plenty of people do run multiple ideas through it and the tagging gets used constantly. So the feature itself was not the mistake. The mistake was building it in response to one email instead of waiting until the pattern showed up in more than one inbox. I got the right answer eventually and paid for it a year early.
Where the account request ended up
I never built accounts. I still get the occasional email asking for them, and I now reply with the export option and an explanation of why, which has changed nobody's mind about wanting a login screen and has satisfied every single person who actually had the problem, because the login screen was never what they wanted in the first place.
The test I use now is not complicated: what is the fear underneath the ask, and does the fix still make sense if it stays rare. Most requests fail one of those quietly, without any drama, which is how it should feel. The loud disagreements are the exception. Most of the work is just refusing to skip the question because someone asked nicely.
Appray walks you through the same territory in eight rounds of questions, then puts every feature you are considering on trial against what you actually said. The result is a Build, Kill or Prove verdict for each one, plus interview questions written from your own answers rather than a template.
It runs entirely on your iPhone or iPad. No account, no sign in, nothing leaves your device, and no AI is involved anywhere in it.