As with anything "it depends".

• Consider the purpose - Is this to show a client? for usability testing? to handover to a development team?/design team?
• Who is your audience? what do they want/need to see? Have they seen this before?/is this a redesign? are you trying to sell it? what kind of areas of the app are they interested in?
• How long have you got?/had? is this a 2 year mega project or a two week throwaway task?
• What existing resources do you already have? is there a mature design system or are you doing everything from scratch?

The point of illustrating these areas is that depending on the answers to these type of questions, the answer you need is very different.

As a few points from personal experience:

• Prototyping every screen may be possible or required if you're planning to hand off the solution to another team and walk away.
• Prototyping every state is likely not possible or desirable, but, if you are needing to hand off resources, prototyping the state of individual components can be helpful, then an implementation know how that component should be used wherever it sits.
• If you try to prototype many states, the ubiquitous "back" behaviour will cause you pain as it's common to have multiple entry points to a single end point, but because "prototyping tools" its often not possible to have a single back button be state away, so you end up with many end screens which are identical except for their entry point and back behaviour. This can be a PITA to maintain.
• I've prototyped only making certain actions interactive, and often this can work, but if usability testing you will likely see more direct completions than indirect, the more things you make work, but aren't part of the desired flow for a test, the most indirect completions you're likely to get.
• I've also prototyped with placeholders, making key areas interactive, but deliberately not implemented. Think like an "under construction" notice. Whilst not desirable for some situations for exec demo's it can be a good way to call out that this area needs more time to deliver to the level of fidelity of the other areas.

EDIT: For execs

On reading your point about this being an "exec version to play with". I would be tempted to initially produce something much less interactive. I would suggest maybe some annotated screens which you feel communicate the overall app, it's key ideas and concepts, and the core flows. Put some of the more important screens into a powerpoint/keynote and email them out. Perhaps in that doc, list what you consider the most important flows and show others as box diagrams or simple screen > screen flows.

Call out aspects which aren't in the prototype and frame it as an illustrative example highlighting "some" of the core flows/key functions to "get a feel", be open an honest about what's not there and why it's not there. Offer them to chance to request a flow be added to the prototype, but explain first why you chose the ones you did and call out the time it will take you add the flow, honestly!

Ideally, do this in person (over zoom etc) to take feedback and answer questions before they get their hands on it. This will lessen frustrations over inclusion/exclusion from the prototype and set expectations.

As with anything "it depends".

• Consider the purpose - Is this to show a client? for usability testing? to handover to a development team?/design team?
• Who is your audience? what do they want/need to see? Have they seen this before?/is this a redesign? are you trying to sell it? what kind of areas of the app are they interested in?
• How long have you got?/had? is this a 2 year mega project or a two week throwaway task?
• What existing resources do you already have? is there a mature design system or are you doing everything from scratch?

The point of illustrating these areas is that depending on the answers to these type of questions, the answer you need is very different.

As a few points from personal experience:

• Prototyping every screen may be possible or required if you're planning to hand off the solution to another team and walk away.
• Prototyping every state is likely not possible or desirable, but, if you are needing to hand off resources, prototyping the state of individual components can be helpful, then an implementation know how that component should be used wherever it sits.
• If you try to prototype many states, the ubiquitous "back" behaviour will cause you pain as it's common to have multiple entry points to a single endpoint, but because "prototyping tools" its often not possible to have a single back button be state aware, so you end up with many end screens which are identical except for their entry point and back behaviour. This can be a PITA to maintain.
• I've prototyped only making certain actions interactive, and often this can work, but if usability testing you will likely see more direct completions than indirect, the more things you make work, but aren't part of the desired flow for a test, the most indirect completions you're likely to get.
• I've also prototyped with placeholders, making key areas interactive, but deliberately not implemented. Think like an "under construction" notice. Whilst not desirable for some situations for exec demo's it can be a good way to call out that this area needs more time to deliver to the level of fidelity of the other areas.

EDIT: For execs

On reading your point about this being an "exec version to play with". I would be tempted to initially produce something much less interactive. I would suggest maybe some annotated screens which you feel communicate the overall app, it's key ideas and concepts, and the core flows. Put some of the more important screens into a powerpoint/keynote and email them out. Perhaps in that doc, list what you consider the most important flows and show others as box diagrams or simple screen > screen flows.

Call out aspects which aren't in the prototype and frame it as an illustrative example highlighting "some" of the core flows/key functions to "get a feel", be open an honest about what's not there and why it's not there. Offer them to chance to request a flow be added to the prototype, but explain first why you chose the ones you did and call out the time it will take you add the flow, honestly!

Ideally, do this in person (over zoom etc) to take feedback and answer questions before they get their hands on it. This will lessen frustrations over inclusion/exclusion from the prototype and set expectations.

As with anything "it depends".

• Consider the purpose - Is this to show a client? for usability testing? to handover to a development team?/design team?
• Who is your audience? what do they want/need to see? Have they seen this before?/is this a redesign? are you trying to sell it? what kind of areas of the app are they interested in?
• How long have you got?/had? is this a 2 year mega project or a two week throwaway task?
• What existing resources do you already have? is there a mature design system or are you doing everything from scratch?

The point of illustrating these areas is that depending on the answers to these type of questions, the answer you need is very different.

As a few points from personal experience:

• Prototyping every screen may be possible or required if you're planning to hand off the solution to another team and walk away.
• Prototyping every state is likely not possible or desirable, but, if you are needing to hand off resources, prototyping the state of individual components can be helpful, then an implementation know how that component should be used wherever it sits.
• If you try to prototype many states, the ubiquitous "back" behaviour will cause you pain as it's common to have multiple entry points to a single end point, but because "prototyping tools" its often not possible to have a single back button be state away, so you end up with many end screens which are identical except for their entry point and back behaviour. This can be a PITA to maintain.
• I've prototyped only making certain actions interactive, and often this can work, but if usability testing you will likely see more direct completions than indirect, the more things you make work, but aren't part of the desired flow for a test, the most indirect completions you're likely to get.
• I've also prototyped with placeholders, making key areas interactive, but deliberately not implemented. Think like an "under construction" notice. Whilst not desirable for some situations for exec demo's it can be a good way to call out that this area needs more time to deliver to the level of fidelity of the other areas.

As with anything "it depends".

• Consider the purpose - Is this to show a client? for usability testing? to handover to a development team?/design team?
• Who is your audience? what do they want/need to see? Have they seen this before?/is this a redesign? are you trying to sell it? what kind of areas of the app are they interested in?
• How long have you got?/had? is this a 2 year mega project or a two week throwaway task?
• What existing resources do you already have? is there a mature design system or are you doing everything from scratch?

The point of illustrating these areas is that depending on the answers to these type of questions, the answer you need is very different.

As a few points from personal experience:

• Prototyping every screen may be possible or required if you're planning to hand off the solution to another team and walk away.
• Prototyping every state is likely not possible or desirable, but, if you are needing to hand off resources, prototyping the state of individual components can be helpful, then an implementation know how that component should be used wherever it sits.
• If you try to prototype many states, the ubiquitous "back" behaviour will cause you pain as it's common to have multiple entry points to a single end point, but because "prototyping tools" its often not possible to have a single back button be state away, so you end up with many end screens which are identical except for their entry point and back behaviour. This can be a PITA to maintain.
• I've prototyped only making certain actions interactive, and often this can work, but if usability testing you will likely see more direct completions than indirect, the more things you make work, but aren't part of the desired flow for a test, the most indirect completions you're likely to get.
• I've also prototyped with placeholders, making key areas interactive, but deliberately not implemented. Think like an "under construction" notice. Whilst not desirable for some situations for exec demo's it can be a good way to call out that this area needs more time to deliver to the level of fidelity of the other areas.

EDIT: For execs

On reading your point about this being an "exec version to play with". I would be tempted to initially produce something much less interactive. I would suggest maybe some annotated screens which you feel communicate the overall app, it's key ideas and concepts, and the core flows. Put some of the more important screens into a powerpoint/keynote and email them out. Perhaps in that doc, list what you consider the most important flows and show others as box diagrams or simple screen > screen flows.

Call out aspects which aren't in the prototype and frame it as an illustrative example highlighting "some" of the core flows/key functions to "get a feel", be open an honest about what's not there and why it's not there. Offer them to chance to request a flow be added to the prototype, but explain first why you chose the ones you did and call out the time it will take you add the flow, honestly!

Ideally, do this in person (over zoom etc) to take feedback and answer questions before they get their hands on it. This will lessen frustrations over inclusion/exclusion from the prototype and set expectations.