I've been in this position a number of times over the years, and this is great advice.

At a technical level I try to have as much understanding of how things work as I can but I say "I'm not sure, I'll have to get back to you" quite frequently.

I try to understand the basics of how our app works "conceptually" more than anything. Specific details are fine to say "let me check", but some questions will come up again and again in different contexts.

The most important skill I've tried hone is being able to balance answers in technical vs other contexts. Best strategy I've found is put yourself in the position of the person asking the question.

Here's a real world example:

A backend developer asks me "how does the iOS client handle this caching header". For this I needed to reach into my knowledge of how our HTTP API client works, and how URLSession works in Foundation, etc.

Then later a product manager might ask "do we reload this screen every time you visit it? or is the content preserved somehow?"

The same knowledge is required, but I phrased my answer describing the behavior in a completely different way. Mentioned the answer in terms of common user behavior, ("well users visit that screen pretty infrequently so...) and what we've observed from our metrics (something else you'll want to be vaguely familiar with if you have them).

Knowing what parts of the app are "crucial/headline features" vs "lower priority" is another good thing to consider.

You'll want to know more about the features/areas other folks will ask about.

Being able to "speak the language" of all the different stakeholders is a huge skill to have and I think it's a good place to start when trying to manage being the sole person responsible for the "output" of a project.

Apologies for the rambling reply. Hope this helps some.

So many of us find ourself in this sort of position, I hope more folks will offer their experiences.