Foundation Model and LLM Cases: A Consulting Framework

Foundation model and LLM cases have split off from generic AI strategy cases because the underlying decision is different: which model, hosted how, at what cost per unit of usage, with what dependency risk. Based on our analysis of recent technology-sector cases, interviewers increasingly present a scenario where the client has already decided to use a large language model, then test whether the candidate can reason about model selection, cost structure, and vendor lock-in — the layer below the “should we do AI” question that most generic AI frameworks stop at.

Why Foundation Model Cases Are a Distinct Case Type

A generic AI strategy case asks whether a company should invest in AI and where. A foundation model case assumes that decision is made and tests something narrower: given that the client will use a large language model, how should they source it, price around it, and protect themselves from the model layer changing underneath them. This is a commodity-input problem dressed up as a technology problem, and interviewers use it to check whether candidates default to “just use the best model” or actually reason about total cost of ownership and dependency risk.

The three variables that make these cases distinct from a standard build-vs-buy case:

The Foundation Model Decision Framework

Four questions determine how a company should approach a foundation-model-dependent product or capability, and they need to be answered in this order — cost and risk conclusions only make sense once sourcing is settled.

flowchart TD
    A[Foundation Model Business Decision] --> B[Model Sourcing]
    A --> C[Cost Architecture]
    A --> D[Differentiation Moat]
    A --> E[Vendor Risk]

    B --> B1[Frontier API vs open-weight vs fine-tune]
    B --> B2[Single model vs multi-model routing]

    C --> C1[Cost per token at target volume]
    C --> C2[Gross margin at scale, not pilot]

    D --> D1[Proprietary data layer]
    D --> D2[Workflow integration vs raw output]

    E --> E1[Deprecation and repricing exposure]
    E --> E2[Switching cost if vendor changes terms]

    style A fill:#1e3a5f,color:#fff
    style B fill:#2563eb,color:#fff
    style C fill:#2563eb,color:#fff
    style D fill:#2563eb,color:#fff
    style E fill:#2563eb,color:#fff

Part 1: Model Sourcing Decision

Most candidates jump straight to “should we build our own model” — almost always the wrong instinct. Training a foundation model from scratch requires hundreds of millions of dollars in compute and data, a bar only a handful of companies in the world can clear. The real sourcing decision sits one level down.

The insight interviewers reward: for the overwhelming majority of companies, “build your own foundation model” is the wrong answer, and the strongest candidates rule it out explicitly with a cost argument rather than skipping past it.

Part 2: Cost Architecture — Where Margin Actually Breaks

Model economics look attractive in a pilot and fragile at scale, because pilots run on small volumes where token costs are invisible relative to headcount saved. Structure your cost analysis around the gross margin at target volume, not the pilot.

Key cost components candidates routinely underweight:

• Output length, not just input length: Providers typically price output tokens at a multiple of input tokens — a feature that generates long-form output (reports, code, summaries) costs meaningfully more per interaction than one that classifies or extracts short answers.
• Context window inflation: Retrieval-augmented workflows that stuff long documents into every call multiply cost per query, often faster than teams model in their initial business case.
• Retry and correction overhead: Hallucination handling — human review, re-prompting, fallback logic — adds cost that rarely appears in the initial ROI model but shows up immediately in production.

A useful gut-check for a case interview: if the AI feature costs more per user per month to run than the incremental subscription revenue it unlocks, the business case fails regardless of how good the output quality is. For the broader mechanics of go-to-market pricing under this cost structure, see AI product launch cases.

Part 3: Differentiation Moat — Where the Value Actually Sits

Since most vendors draw on the same small set of underlying model families, the model itself is rarely the differentiator. Interviewers use this case type specifically to test whether a candidate can locate value somewhere other than “our AI is smarter.”

Three places defensibility can actually come from:

1. Proprietary data layer: Fine-tuning or retrieval grounded in data competitors cannot access — historical transaction records, internal documents, domain-specific labeled examples.
2. Workflow integration: Being embedded in the tool where the user already works beats a technically superior standalone product that requires switching context.
3. Trust and validation infrastructure: Confidence scoring, audit trails, and human-in-the-loop review that make output usable in regulated or high-stakes workflows — a moat competitors underinvest in because it isn’t visible in a demo.

If none of these three apply, the honest answer in a case interview is that the AI feature is a temporary parity move, not a durable advantage — and the recommendation should be priced and resourced accordingly.

Part 4: Vendor Risk and Model Churn

Foundation model dependency introduces a risk category standard software vendor selection does not: the underlying model itself gets deprecated, repriced, or leapfrogged by a competitor roughly every 6-12 months.

flowchart LR
    A[Vendor Risk Exposure] --> B[Deprecation Risk]
    A --> C[Repricing Risk]
    A --> D[Capability Leapfrog Risk]
    B --> B1[Model sunset with short migration window]
    C --> C1[Per-token price changes outside your control]
    D --> D1[Competitor ships on a materially better model]

Mitigations candidates should raise: designing an abstraction layer that lets the product swap underlying models without a full rebuild, maintaining evaluation benchmarks so a model swap can be validated quickly, and avoiding deep coupling to any single vendor’s proprietary features (fine-tuning APIs, tool-calling formats) that would be expensive to unwind. For the wider build-vs-buy toolkit this risk framing draws from, see tech build vs. buy decision cases.

Common Case Scenarios

Scenario 1 — Sourcing decision for a new feature. A B2B SaaS company wants to add a document-analysis feature powered by an LLM. Should they call a frontier API, self-host an open-weight model, or fine-tune? Work through Part 1 first — at their expected volume, does a fixed self-hosting cost beat variable API pricing, and does the use case need frontier-level reasoning or is a smaller, cheaper model good enough?

Scenario 2 — Vendor concentration risk. A company built its core product on a single foundation model provider. That provider just raised prices 40% with 90 days’ notice. Diagnose the switching cost (Part 4), then structure a response: absorb the cost, pass it to customers, or invest in a multi-model architecture to reduce future exposure.

Scenario 3 — Margin erosion at scale. An AI feature that looked profitable in a 500-user pilot is losing money at 50,000 users. Walk through Part 2 to find where the cost model broke — usually output length, context window growth, or retry overhead the pilot never surfaced — before recommending a pricing or architecture fix.

Key Takeaways

• Foundation model cases assume “use an LLM” is already decided and test model sourcing, cost architecture, differentiation, and vendor risk instead
• Training a foundation model from scratch is the wrong default answer for nearly every company — rule it out explicitly with a cost argument
• Structure cost analysis around gross margin at target volume, not pilot economics — output length and context window growth are the most commonly underweighted cost drivers
• Since most vendors draw on the same underlying models, differentiation has to come from proprietary data, workflow integration, or trust infrastructure — not the model itself
• Vendor risk is a distinct category from standard software risk: model deprecation, repricing, and capability leapfrogs happen on a 6-12 month cycle
• A strong recommendation includes an abstraction layer or evaluation process that lets the client swap models without a full rebuild

Practice Foundation Model and LLM Cases

Explore strategic decision cases and cost reduction cases in our case library, or review AI and emerging tech cases for the broader AI strategy layer this framework sits underneath.

To build real judgment on this framework, practice matters more than reading about it. CasesCoach’s Guided Mode walks you through a foundation model sourcing case with hints at each decision point — useful for building the structure before you can hold it under pressure. Once the framework is second nature, switch to Expert Mode to simulate full interview pressure with no hand-holding. For a scenario like the vendor-concentration case above, Chat with Case lets you work an actual foundation model case end-to-end — background, framework selection, data analysis, and recommendation — while an AI partner pushes back on your logic in real time.

Every session scores you across five dimensions — Structure, Analysis, Communication, Business acumen, and Math — so you know exactly where the gaps are before the real interview.

Sign up free to try 3 full cases plus an AI Mock Interview session. Ready to go deeper? Pro unlocks all 835+ cases in the library and multiple AI Mock Interview sessions. Start with AI Mock Interview or check pricing for plan details.