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

This is a great question that gets at the heart of content modeling philosophy—and one that many developers wrestle with when their project feels more "app-like" than "content-like."

When "Landing Page" makes sense as an entity:

You're right that specialized purpose is a key factor. A "Landing Page" becomes a legitimate entity when it has distinct characteristics, behaviors, or content needs that differentiate it from other page types. According to Sanity's structured content principles, you should model content based on what it is, not what it looks like. So a Landing Page entity makes sense if landing pages have:

• Unique metadata requirements (conversion tracking, A/B test variants)
• Different lifecycle management (temporary campaigns vs. permanent content)
• Specific content patterns (hero + CTA + social proof)
• Distinct editorial workflows or permissions

Your situation sounds different:

From what you're describing—where everything is essentially "What we do" entries that kick people to videos/slides, and the "fields" feel more like UI configuration than content—you're hitting on something important: you might be using Sanity as a configuration management system rather than a content management system.

And here's the thing: that's actually okay. Sanity can absolutely serve as a "settings repository" for app-like experiences. The framework is flexible enough to handle this. But your instinct that it feels "not-right" is worth listening to.

The frame of mind you need:

1. Ask: "What varies?" If every entry has the same structure and the only differences are the specific values (title, video URL, thumbnail), you probably have one document type with many instances, not many document types.

2. Model the concepts, not the screens. Even in an app-like experience, try to identify the underlying entities. The content modeling lesson emphasizes entity-based modeling—focusing on unique, distinguishable, and self-contained things or concepts rather than pages. Are these really "services"? "Offerings"? "Learning modules"? Name them for what they are in the business domain, not where they appear.

3. Use references and composition. If everything could fall under a single taxonomy (as you mentioned), that's a signal. You might have one Service document type, with references to Video, Presentation, and maybe a Category taxonomy. The "landing" becomes a composition pattern on the frontend, not a content type.

4. Separate content from configuration. If some fields feel "interface-y," consider: are these content fields or are they UI behavior flags? Things like "opens in modal" or "shows navigation" might belong in your frontend code or a separate app configuration document, not scattered across content entries.

Avoiding lock-in:

Your concern about lock-in is smart. The structured content approach actually helps here—by keeping content presentation-independent and focused on meaning, you make it more portable. If you model a Service with its essential attributes (description, associated media, category), that data can migrate anywhere. If you model a LandingPageWithSpecificLayoutBehavior, you've coupled your content to your current implementation.

Bottom line:

If your content is genuinely homogeneous and the variation is mostly presentational, embrace a simpler model with fewer document types and more instances. Use Sanity's flexibility (portable text, references, arrays) to handle the variations within that model. You're not "misusing" Sanity—you're just on the configuration-heavy end of the content-to-configuration spectrum, and that's a valid place to be.

The fact that you're thinking about this means you're already on the right track. Carrie Hane's book "Designing Connected Content" covers exactly these kinds of decisions about when something qualifies as its own entity versus being an instance of a shared type—definitely worth a read if you're wrestling with these questions regularly.