SaaS Mountain — The Incumbent Model Yegge's Agents Are Escaping

Source: Steve Yegge, "Welcome to Gas City," Apr 24, 2026 (primary); "Welcome to Gas Town," Jan 1, 2026 (context)
Related: steve-yegge-gas-town, steve-yegge-gas-city, steve-yegge-beads

The Mountain Metaphor

SaaS Mountain is Yegge's term for the incumbent model of software delivery: monolithic, one-size-fits-all SaaS products that developers and organizations climb to access functionality. Salesforce, Workday, ServiceNow, Jira, Confluence, Linear — the great SaaS platforms of the 2010s and early 2020s.

The mountain metaphor is apt because:
1. It's a climb. SaaS platforms are complex, require significant configuration and customization, and demand ongoing maintenance. Getting to the top (full value) takes months or years.
2. The view from the top is good but expensive. You get a integrated, supported, well-documented product — but you pay $30k+/year and you get exactly what the vendor decided you need.
3. It's crowded up there. Everyone is on the same mountain, taking the same trails, stopped at the same bottlenecks.
4. It's hard to get down. Once you've invested in a SaaS platform — migrated data, trained people, built integrations — the switching cost is prohibitive. You're on the mountain whether you like it or not.

The Cracks in the Mountain

Yegge identifies three fundamental problems with SaaS Mountain that are becoming terminal in the AI agent era:

1. You Only Use ~20% of It

Every SaaS platform is designed for maximum generality. Salesforce tries to serve every possible sales workflow. Jira tries to serve every possible project management approach. The result: you pay for 100% of the product and use 20% of it. The other 80% is configuration options, edge-case features, and compatibility shims you never touch.

Gas Town users discovered this empirically: a non-technical staff member rebuilt a $30,000/year SaaS product in Gas Town. Not a prototype, not a toy — production-quality replacement for a real SaaS dependency. The implication: you only need to build the 20% of a SaaS you actually use. SaaS Mountain is cracking from the bottom up.

2. SaaS Is Not Agent-Native

SaaS products were designed for human users. They have UIs optimized for human attention, workflows optimized for human decision-making, and APIs that assume human-scale usage patterns. AI agents trying to use SaaS products encounter friction at every turn:

  • CAPTCHAs and anti-bot measures
  • Rate limits designed for human browsing
  • UIs that require visual parsing rather than structured data access
  • Permissions models designed for human identity, not agent identity

Agent-native tooling (like Gas Town / Gas City) is designed from the ground up for AI agents: git-backed data, SQL queryability, structured work primitives (Beads), no visual UI to parse.

3. The Composability Problem

SaaS products are islands. Salesforce doesn't compose naturally with Workday, Workday doesn't compose naturally with Jira. Integrations are bolted on via third-party middleware (Zapier, Workato, MuleSoft) that creates brittle, opaque pipelines.

Gas City's pack model inverts this. Packs are designed to compose. Every pack shares the same Bead substrate, is addressable via the same protocol, and can be wired to any other pack. The integration problem is solved at the framework level, not by adding another middleware layer.

Escape Velocity

Yegge frames Gas City as the escape vehicle from SaaS Mountain. The pattern:

  1. Start small. A single team uses Gas Town internally. Agents handle work without SaaS dependencies.
  2. Expand. More teams join. The Gas Town deployment becomes a dark factory that competitors (internal teams, external contractors) can plug into via the Wasteland.
  3. Platform. Organizations start building custom packs on Gas City, sharing them with each other. A library of composable, agent-native building blocks emerges.
  4. Ecosystem. The Wasteland connects all these factories into a federated economy. Work flows to the best Rigs regardless of organizational boundary.

This is not a revolution — it's a gradual escape. But Yegge believes the direction is clear: the next generation of software infrastructure will be built by agents, for agents, on agent-native frameworks. SaaS Mountain will not disappear, but its dominance will be broken.

The 20% Rule in Practice

Yegge's "20% rule" is worth examining more closely. The empirical observation: most SaaS products have a Pareto distribution of usage. 80% of users use 20% of features. 80% of the value comes from 20% of the functionality.

This isn't a knock on SaaS vendors — it's an architectural inevitability of building for generality. But in the AI agent era, building for generality is a liability, not an asset. Agents don't need the other 80%. They need the 20% that matters, implemented as composable primitives they can wire together as needed.

Gas City's pack model embodies this: instead of one massive integrated product (SaaS Mountain), you have dozens of small, focused packs that compose into exactly the system you need. The composition is done by agents, for agents, with no UI required.

Kelly Parallel

SaaS Mountain Concept Kelly Equivalent
SaaS as monolithic, general-purpose tool Kelly's critique of monolithic agent systems — systems that try to do everything rather than composing specialized agents
"Only use 20%" observation Kelly's 80/20 rule for automation — most of what SaaS does is routine; the interesting work is the exception
Agent-native tooling vs SaaS APIs Kelly's autonomous computer control — agents need direct system access, not UI-mediated API wrappers
Pack composition (composable by design) Kelly's BMAD agent definitions — modular, composable agent specs that compose into factories
Escape from SaaS Mountain Kelly's vision of autonomous companies — organizations that build their own tooling rather than buying SaaS
Federated Wasteland economy Kelly's autonomous company marketplace — independent factories trading work in a market

Key gap: Kelly doesn't have an explicit "SaaS Mountain" framing — a named, coherent critique of the incumbent model. Kelly's critique of SaaS is implicit in his preference for building over buying (autonomous companies build their own tooling). Yegge's SaaS Mountain framing is more accessible and communicable to non-technical stakeholders.

Key distinction: Kelly's factory model is already agent-native by design — it was conceived for AI agents from the start. Yegge's contribution is showing why SaaS Mountain fails for agents (via concrete examples like the $30k replacement), which makes the case for Kelly's approach more concretely.

Source Attribution

  • Steve Yegge, "Welcome to Gas City," Apr 24, 2026 — SaaS Mountain framing and the $30k replacement anecdote
  • Steve Yegge, "Welcome to Gas Town," Jan 1, 2026 — context on building tooling rather than using off-the-shelf

Bibliography

steve-yegge-beads, steve-yegge-gas-city, steve-yegge-gas-town