Discussing the categorization of landing pages and how to approach modeling for an app-like project in Sanity.

If we're breaking things up into what they "mean" and trying not to be strict about thinking of things in presentational terms, what qualifies "Landing Page" to be a (potential) entity? Is it because it has a specialized purpose?
I didn't want to hijack
a thread , but I've been thinking about this kind of thing based on a project someone needed help with, where the end result was more of an app than a site and, on the front end, really, really tied to presentation.
In other words, they only ever want it to be this one kind of thing, that clicks here and opens this, etc. and most of the landings (or equivalents) are just intros and blurbs to kick people off to a video or slide presentation.

In those cases, what kind of frame of mind do I need to be in to help Sanity help me, from the perspective of modeling? In the outline all their entries except for about/career style pages are "What we do" which is essentially like a service listing. But, for an app, all the
fields they'd need to be able to have handy to make the thing work and tweak/customize feel more interface-y than topical. In fact, it almost feels like every 'landing' they have could fall under a single taxonomy.
Perhaps if that fits, it's appropriate, and it absolutely can be made to work that way, using Sanity as the world most easy-to-use "settings repository" but it feels....not-right. And the last thing I want to do is be the originator for lock-in.

I wouldn’t put Landing Page in a strategic content model, but it is often a document type in the CMS.

Have you ever dealt with a similar circumstance where something either seemed to defy categorization in a useful way, or where a model might not have even been appropriate? Or is it just a matter of "finding" it?
The only thing I can really think of is leaning into the "mirror the real world" part and expanding what each talked-about thing is, in order to be able to have entities that make sense, and then deliberately whittle back down to just taking the couple pieces of info (or addressing the couple fields) that are strictly necessary.

They wouldn't even need to necessarily
address all there is to say on them, they can still just target only the bits they care about right now, but it could adapt and grow if they wanted to use it as a repository for other eventual end uses.

What I haven’t gotten to yet in the guide (there will be another chapter coming) is this reality:

Your content model will get you 80%-90% of any website’s pages. The remaining 10%-20% will be pages that are specific to that website – things like About, Privacy Policy, and Index pages (like for News items or Events - things that list or collect one or two content types).

That is where you have to consider how you’ll set up Sanity to accommodate the page on the website. Some will be Singletons (Home) other will be able to be templated and reused. In these pages, you need to consider what is part of the display template and what is part of the document type in Sanity.
There are plenty of web pages that end up having just a field or two and then a bunch of references (often landing pages) or a full listing (index) that get formatted via the front-end code. This is where I design the content to communicate what I want to happen and the designers and developers make it happen.

That makes sense and is reassuring. Thank you for your valuable time, .
Looking forward to the next chapter!

(If I am being honest singletons and settings pages are kind of a guilty pleasure sometimes because there's instant gratification and a feeling of great stability
🙂 )