Cutting was harder than building. Every item on that list was there because at some point it had seemed obviously necessary, and by the time I sat down to trim it I could no longer remember which ones I had actually thought about and which ones I had just written down because they sounded like things an app has.
Ranking them did not help. When you put your own features in order of importance, you get a list where everything is important, sorted slightly. The useful question is not what matters most. It is what can be missing on the first day without the thing being pointless.
Four tests that actually cut things
These are the ones that survived. They work because none of them ask you how much you like the feature.
Does it help on the first day, or only after someone is already succeeding?
A lot of features are for people who already got value out of your product. Export, history, themes, sharing, bulk actions. They are real and people will want them, but they solve problems you only have after the thing has already worked for you once.
None of that belongs in a first version. If nobody gets to day one, nobody ever needs day thirty. I kept history in Appray and cut sharing, and I think that split was right, because people run more than one project quickly but they have nothing worth sending anyone until the first report exists.
Can you do it by hand for the first fifty users?
This one is uncomfortable and it is the most effective test on the list.
If the answer is yes, do it by hand. Onboarding emails, sorting out a broken import, answering a question the FAQ would answer. Doing it manually is slower per user and much faster overall, because you learn what people actually get stuck on instead of guessing and building the wrong automation.
The trap is that manual work feels unprofessional. It is not. It is the cheapest research you will ever run, and it stops being possible the moment you have real volume, so you only get one window to do it.
If it disappeared overnight, would anyone say anything?
Imagine the feature is gone tomorrow morning and nobody was warned. Do you get an email about it?
For most features on a first list the honest answer is no. Not because they are bad, but because nobody knows they were supposed to exist. There is no expectation to violate yet. This is the one real advantage of not having launched, and it goes away permanently the day you do.
Would you delay the launch by two weeks for it?
Say it out loud with the actual dates. Not "is this important" but "am I willing to have nothing in anyone's hands for another fourteen days so this can be in the first version".
Almost everything fails this. The few things that pass are your MVP, and you now have a much shorter list than you started with.
Where the cut features should go
Not deleted. Parked somewhere you will actually look, with one line about who asked for it and why you thought it mattered. Most of them will still look silly in three months, which is the useful outcome. A couple will come back because a real person hit the exact problem you predicted, and that is worth knowing about yourself.
What you should not do is keep them in the main list greyed out or marked "later". Later is where features go to keep looking alive without ever being decided on, and a list full of maybes makes the real list harder to read.
The one I got wrong
I cut going back to previous answers. My reasoning was that the questions are quick, so if someone wanted to change something they could start again.
That was nonsense, and I knew it was nonsense within a day of watching someone use it. People change their mind halfway through precisely because the questions are making them think, which is the entire point of the product. Making them throw the session away punished the exact behaviour I wanted.
The tests above did not catch it, because it passed all four. It would have been noticed if it vanished, it could not be done by hand, and I would have delayed for it if I had understood. I had simply answered the questions wrong, confidently.
Which is the honest limit of any method like this. It makes your reasoning visible so you can check it later. It does not make the reasoning correct.
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.