Sunil Venkataram
Back to garden
•
🌰 seedling
Full Stack Down vs Full Stack Up - Two Directions for AI Application Vertical Integration
type/noteaisaasinvesting

Full Stack Down vs Full Stack Up — Two Directions for AI Application Vertical Integration

The three-layer frame

Tanay Jaipuria (Wing VC) articulates the AI product stack as three layers:

  1. Bottom layer — the model. Foundation capability. Originally rented from OpenAI/Anthropic/Google; increasingly fine-tuned, distilled, or trained in-house.
  2. Middle layer — the application or agent. UI, workflow, context management, user data, integrations. This is the layer where most AI startups live today.
  3. Top layer — the service. The human or automated final-mile work needed for prompting, review, validation, and outcome delivery. The layer that touches the customer’s actual business result.

Historical application companies lived purely in the middle. Contemporary AI application companies are expanding outward in opposite directions — some down into models, some up into services, some eventually both.

Full Stack Down — Integration into the model layer

What it looks like: The application company trains or fine-tunes proprietary models tailored to its specific domain, rather than relying purely on a general-purpose frontier model from OpenAI/Anthropic/Google.

Examples:

  • Cursor — shipped Composer 2, a frontier-level coding model built on Kimi K2.5 as base, extended through continued pretraining and reinforcement learning on long-horizon coding tasks. Cursor is no longer just a Claude/GPT wrapper — it is becoming a model company for its specific domain.
  • Intercom — Fin Apex, described by CEO Eoghan McCabe as “the age of vertical models.” Powers essentially all English-language customer chat and email conversations through Intercom’s platform.
  • Harvey, Cognition, Sierra — increasingly shaping, tuning, routing, and training intelligence around their specific domains (legal, software engineering, customer service respectively).

Why this works — the training-data flywheel:

Every interaction in the application layer captures agent behavior traces: prompts that worked, prompts that failed, user acceptances, user rejections, follow-up corrections, workflow patterns. These traces are proprietary and uniquely valuable for training a model that serves this specific domain better than any general-purpose model can. The flywheel is:

Superior product → more usage → more traces → better proprietary model → better product → more usage…

Once the flywheel is running, the application company accumulates a data moat that no pure model company and no competing application can replicate. The proprietary model becomes the reason customers stay.

Secondary motivations:

  • Cost and latency. A fine-tuned smaller model delivers sufficient performance at a fraction of the inference cost, and faster. Frontier-model APIs are fast relative to humans but slow relative to interactive software — dropping to a fine-tuned 7B model in-house can unlock workflows that the application can’t afford at frontier API rates.
  • Differentiation. When all competitors use the same underlying foundation model, there is no technological differentiation between products — only UX and integration. A proprietary model is one of the few genuinely defensible technical moats available to an application company in 2026.
  • Optionality against frontier-lab pricing. An application company fully dependent on a frontier lab’s API pricing is at the mercy of that lab’s business decisions. Owning model capacity in-house provides negotiating leverage and survival optionality if frontier pricing spikes or terms change.

What this requires: Substantial training infrastructure, ML research talent, and the willingness to absorb the costs of running a parallel model-development effort alongside the application business. Not every application company can afford the Full Stack Down motion. The ones that can are building structural moats the others can’t.

Full Stack Up — Integration into the service layer

What it looks like: Rather than selling software to a customer who then runs the service themselves, the company owns the end-to-end process and delivers the outcome directly. The customer pays for the result (contract reviewed, insurance policy written, legacy code modernized) rather than for the tool that helps produce it.

Examples:

  • Crosby AI — combines software, AI, and actual attorneys. Co-founder Ryan Daniels calls this category a “Neofirm.” See Neofirms - AI-Native Professional Services as a New Category.
  • WithCoverage and Harper — AI-native insurance brokerages. They don’t sell insurance software; they are the broker, with AI doing most of the work internally.
  • Mechanical Orchard — AI-native software modernization services firm. They don’t sell code-migration tools; they sell completed migrations of legacy systems.

Why this works:

AI remains imperfect. For many enterprise-critical tasks, the customer cannot accept a “usually correct” output — they need confidence the work is right before they act on it. A Full Stack Up company can fill in the gaps where AI falls short with human oversight, QA, and domain expertise, while still capturing most of the productivity gains AI enables on the back end.

The customer doesn’t care about the blend. They pay for the outcome and get it faster and cheaper than they would from a traditional services firm, while still getting the accountability and quality assurance of a real vendor of record. The AI-native firm captures margin that neither pure-software companies nor traditional services firms could capture.

The deeper argument: selling software demands that customers do the work of making the software produce results. Selling outcomes relieves the customer of that burden entirely. In a world where customers are overwhelmed by the operational burden of adopting AI, the Full Stack Up positioning removes that burden and captures the budget that would otherwise go to traditional services.

Where the two directions converge

The most durable trajectory is probably to integrate in both directions over time:

  • A Full Stack Down company that has trained a proprietary vertical model can also start delivering outcomes by wrapping its model in a service layer — now it is both application + model + service.
  • A Full Stack Up company that has accumulated enough service delivery data can start training proprietary models on that data — now it is both service + application + model.

Either path converges on the same endpoint: a company that owns the full stack from model through application through service delivery. The order of integration differs, but the eventual structure is similar.

Historical analog: Chris Dixon’s 2014 essay “Full-Stack Startups” argued that startups in traditionally integrated industries (banking, healthcare, insurance, transportation) should control the entire value chain rather than licensing technology to incumbents. Uber is the canonical example — rather than building taxi dispatch software and licensing it to taxi companies, Uber ran the rides directly. The AI-era version of this argument is Full Stack Up, and it is being applied to professional services categories that Dixon’s 2014 frame didn’t yet reach.

Investment implications

  • Pure application companies are in a squeeze. If the company stays in the middle layer, it has two risks: a frontier-lab model improves and subsumes the application’s reason to exist, or a competitor goes Full Stack Down and builds a better proprietary model in the same vertical. The application-only position is fragile.
  • Full Stack Down is capital-intensive but defensive. Training proprietary models is expensive and requires ML talent the application company didn’t originally hire. The payoff is a structural moat that can’t be replicated by wrapping the same frontier model differently.
  • Full Stack Up is margin-rich but operationally heavy. Owning outcomes means owning hiring, training, quality control, and delivery operations the software company didn’t originally have. The payoff is capturing services-firm margins on top of software-firm scalability.
  • Some verticals favor one direction more than the other. Engineering tools (coding assistants, DevOps agents) favor Full Stack Down because the usage traces are technical and rich. Professional services (legal, insurance, tax) favor Full Stack Up because the customer’s actual need is outcome delivery with liability transfer.

How this connects to other tonight’s theses

Full Stack Up is in many ways the extreme version of several other frames that surfaced tonight:

  • “Doing the work, not running the business” (Run the Business vs Do the Work - The AI-Era Vertical SaaS Shift) — Full Stack Up takes this to its logical conclusion: the company doesn’t sell software at all, it sells the work itself.
  • “Agent is the customer” (Claws - Persistent Looping Agents as App Replacement, Seat-Based to Token-Based SaaS Pricing Transition) — Full Stack Up companies often price per outcome or per transaction, which is the native pricing model when an agent (not a human) is consuming the service.
  • “Hero User wedge” (Hero User Strategy - Native AI’s Wedge Into Vertical Software) — Full Stack Down companies often use Hero User wedges to acquire the usage traces that fuel their training-data flywheel.
  • “System of Action” (System of Action - Evolution Beyond System of Record) — Full Stack Up companies ARE the system of action for their customers. The outcome is the action, and the company owns it end to end.

Fifth independent source converging on the same underlying thesis: value in the AI era migrates toward whoever owns the outcome, not whoever owns the tool that helps produce it.

Backlinks (3)
Connected Notes