Overview

# The Vertical SaaS Playbook Is Breaking Down—and Studio Models Are Filling the Gap Sahil Lavingia recently described Gumroad's operating model in a way that should make every vertical SaaS founder uncomfortable: a $20M ARR business running on $1M in costs, no full-time employees, and a distributed team of contractors who ship features when they're needed—not when a roadmap says they're due. This isn't a lifestyle business. It's a different set of economics entirely. And while Gumroad's model is specific to their context, the underlying pattern is showing up everywhere in the AI-native space: small, operationally lean teams are outmaneuvering traditional product companies not by building better software, but by treating software as a _service delivery mechanism_ rather than a scalable asset. The wedge isn't feature parity. It's operational intimacy at the workflow level—and vertical SaaS companies built for repeatability are structurally disadvantaged against it. ## The SaaS Assumption That's Coming Apart Vertical SaaS won the last decade by solving a specific problem: if you could build software that worked for 70% of a vertical's workflows, you could sell it to thousands of customers and amortize development costs across a huge base. The economics were clear—high upfront investment, but massive leverage once you hit product-market fit. That model assumed two things: 1. **Customization was prohibitively expensive.** If a customer needed something outside your product's scope, you either said no or charged enterprise prices for professional services. Custom work didn't scale, so you optimized for the common denominator. 1. **Software development was the bottleneck.** Building features took quarters, not weeks. Validation cycles were long. You needed a product org, a roadmap, and enough runway to survive the build-measure-learn loop. Both assumptions are breaking down in the AI-agent era. Customization is no longer prohibitively expensive when you can scaffold a working automation in days using LLM-powered agents, pre-built integrations, and lightweight orchestration layers. And software development is no longer the bottleneck when the _workflow logic_ can be expressed in natural language, tested against real data, and deployed without rewriting your entire stack. The result: a three-person studio team can now ship a bespoke AI workflow for a single customer faster than a traditional SaaS product team can validate whether that workflow should be a feature. ## What Studio-Model Teams Do Differently Studio models aren't just "agencies with better margins." They operate under a different set of constraints: - **No product roadmap.** Work is scoped per engagement, not amortized across a customer base. If a client needs a custom agent that monitors Slack, pulls data from their ERP, and triggers a workflow in their CRM, you build that—once. You don't abstract it into a feature for everyone. - **Operational intimacy over scalable repeatability.** You're not trying to solve for the median customer. You're solving for _this_ customer's exact workflow, with their specific data sources, edge cases, and internal handoffs. That level of specificity is a liability in a SaaS model (too many one-off requests). In a studio model, it's the entire value proposition. - **Software as a service delivery mechanism.** The AI agent or automation isn't the product—it's the tool that delivers the service. You're not selling seats or usage tiers. You're selling the outcome: "Your sales ops team no longer manually reconciles CRM data with your billing system." This isn't a new idea in services businesses. What's new is that AI agents make it economically viable at much smaller scale. You don't need a 50-person delivery team to handle workflow customization. You need two people who understand the customer's process and one person who can wire up agents, APIs, and orchestration logic. ## Where SaaS Companies Get Stuck The challenge for vertical SaaS isn't that they can't build AI features. Most are already adding LLM-powered summarization, predictive analytics, or chatbot interfaces to their products. The challenge is that _AI features inside a SaaS product_ still operate under SaaS constraints: - You have to build for the common denominator. If 30% of your customers need a specific workflow automation, you have to decide whether it's worth roadmap prioritization. A studio team just builds it for the one customer who needs it. - You have to maintain backward compatibility. Every new feature has to work within your existing data model, UI paradigm, and integration architecture. A studio team can start from the customer's actual workflow and build backward. - You have to defend pricing and positioning. If you add a powerful AI feature, do you gate it behind a higher tier? Do you charge per-use? Do you bundle it into the base product and risk commoditizing your own pricing? A studio team doesn't have a pricing page to defend—they scope the engagement based on the value delivered. The result is that SaaS companies are structurally slower to ship the exact workflow their customer needs, even when they have more resources and better brand recognition. ## The Competitive Wedge Is Process-Level Specificity Here's the pattern we're seeing with Lukco clients: A vertical SaaS company has a product that handles 70% of a customer's workflow. The customer loves it. But there's a 30% gap—some manual process, some data transformation, some handoff between systems—that the product doesn't cover. In the old model, the customer either: - Lived with the gap (and built a spreadsheet workaround) - Paid for professional services (if the SaaS company even offered it) - Bought a second product to fill the gap (and dealt with integration headaches) In the AI-agent model, a studio team can come in and say: "We'll build you an agent that sits on top of your existing SaaS product, pulls the data it's missing, and automates the handoff." The agent doesn't replace the SaaS product. It _completes_ the workflow. And because it's custom-built for this customer's exact process, it works better than any feature the SaaS company could ship for the general market. That's the wedge. Not "better software," but "software that actually matches how you work." ## What This Means for Founders and Operators If you're building or operating a vertical SaaS company, the studio-model threat isn't hypothetical. It's already happening in every vertical where workflows are complex enough that no single product can cover 100% of the process. The response isn't to pivot to a studio model yourself—most SaaS companies are structured wrong for that, and it would destroy the leverage that makes SaaS valuable in the first place. The response is to recognize where your product is vulnerable: - **Identify the workflow gaps your customers are solving with manual processes or duct-tape integrations.** Those are the wedges where a studio team can come in and deliver more value than your next roadmap feature. - **Decide whether you're competing on repeatability or specificity.** If you're betting on repeatability, double down on the workflows you can standardize and accept that you'll lose the long-tail customization work to studio teams. If you're betting on specificity, you need to restructure how you deliver—and price—custom work. - **Build your product to be composable.** The best defense against being displaced by a studio team is to make your product the _foundation_ they build on top of. If your APIs are good, your data model is flexible, and your integrations are robust, a studio team will use your product as the system of record and layer agents on top—rather than replacing you entirely. The vertical SaaS playbook isn't dead. But the assumption that you can win by building one product for an entire vertical is breaking down. The new competitive landscape includes teams that don't need to scale the same way you do—and that's a structural advantage, not a temporary arbitrage. If you're a founder or operator trying to figure out where AI agents fit in your stack, the question isn't "Should we add AI features?" It's "Are we competing on repeatability or specificity—and do our economics support the answer?" Because the studio teams building on top of you have already made that choice.