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 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.
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.
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