If I want to build a feature that I know would need a lot of work so I’d like to make it paid, I note it down. That’s it, I just leave it there, and focus on getting the app launched as free first.
After the launch, feedback will guide you through what noted features to act on, and even add some more.
Launching it as free also gives you time to iron out the inevitable edge cases that won’t appear in your tests. People will have lower expectations, and feedback will contain less angry tone, which is usually a big demotivator.
The “launch early” phrase you keep reading in maker circles, makes a lot of sense for indie devs. It’s easiest to validate an idea, and get help on the direction of the app. Your idea of what the app should be is not always the best idea, user feedback can help fine tune that.
However if you have a very specific vision, and “if someone pays, good, if no one pays, still good”, then disregard what I said above. Keep working on your vision, something unique might sprout out of that.
EDIT: I realized I might not have answered your actual question. Because I always build apps to fix a problem of my own, I make free only what’s essential for that problem. Like what I would do in a script, but with just a bit of polish and UI for it to be usable by non tech users as well.
That’s how Clop launched: first it was a single Swift file that checked the clipboard for images in a loop and ran pngquant on them. I would run that at the command line. Then I packaged it as an app with minimal UI and released it as free.
Most of everything else will be paid. That’s what happened with video and PDF optimization on Clop.
But if it’s an improvement on an existing free feature, I will add it for free. That’s what I did with ignoring specific types of images from the clipboard, or detecting Universal Clipboard etc.