The New SaaS: API-First, MCP-Ready, UI-Optional
Two tweets, posted a month apart, crystallize a shift that's been building for years.
The common thread: API-first and MCP-first, not UI-first.
The Numbers Back It Up
The SaaS index dropped 6.5% in 2025 while the S&P gained 17.6%. Seat-based pricing is collapsing under a simple question: if one user with an AI agent can do the work of ten, why pay for ten seats?
Gartner predicts that 40% of enterprise apps will embed AI agents by end of 2026. Bain's analysis projects that within three years, routine tasks shift from "human + app" to "AI agent + API."
The tweets above aren't predictions. They're describing what's already happening. Craft moving off Zendesk because they need an API-first backend. Companies balking at $20K/year just for AI integration access.
MCP is becoming what HTTP was for the web—the standard protocol for agent connectivity.
What "New SaaS" Actually Looks Like
Traditional SaaS was built for humans clicking buttons. The API was an afterthought—limited, inconsistent, poorly documented.
The new SaaS inverts this:
- API that's complete, not an afterthought
- MCP server so agents can use it directly
- Documentation for humans AND agents
- UI becomes optional—or user-built
The False Choice: Frontend vs Headless
Most frameworks force you to pick. "Headless" usually means no frontend at all. You get a great API but ship nothing users can actually see.
But users still want UIs sometimes. The real ask isn't "headless or frontend"—it's API-first with optional, flexible UI.
You shouldn't have to sacrifice the frontend to be API-first. You shouldn't have to build the MCP server separately from the API. The architecture should give you all three from a single source.
ont-run: Built for the New SaaS Era
With ont-run, you define your functions once in a single ontology:
export default defineOntology({
functions: {
createProject: {
description: 'Create a new project',
access: ['authenticated'],
inputs: z.object({
name: z.string(),
description: z.string().optional(),
}),
outputs: z.object({
projectId: z.string(),
createdAt: z.string().datetime(),
}),
resolver: createProject,
},
inviteCollaborator: {
description: 'Invite a user to collaborate on a project',
access: ['projectOwner'],
inputs: z.object({
projectId: z.string(),
email: z.string().email(),
role: z.enum(['viewer', 'editor', 'admin']),
}),
outputs: z.object({
inviteId: z.string(),
status: z.enum(['sent', 'pending']),
}),
resolver: inviteCollaborator,
},
},
});
From this single definition, ont-run automatically generates:
- REST API (
POST /api/createProject,POST /api/inviteCollaborator) with validation, authentication, and access control - MCP server with tools that agents can call directly
- Frontend components for human users
The MCP server isn't extra work—it's a byproduct of defining your ontology. The API and MCP tools are always in sync because they're generated from the same source.
The Opportunity
Every bloated SaaS has a "headless" competitor waiting to be built. The tweets at the top describe the market opportunity: build reliable infrastructure with a complete API, rich MCP support, and documentation for both humans and agents. Charge 10% of what the incumbents charge.
The hard part used to be keeping your API and MCP server in sync, maintaining consistent access controls, generating documentation. ont-run solves this by making them all derived from the same ontology definition.
You define once. You get everything.
The Destination
The tweets describe where software is heading: API-first, MCP-ready, UI-optional. Users will vibe their own interfaces. Agents will call your functions directly. The UI-first SaaS that can't adapt will be disrupted by API-first players that can.
ont-run is built for getting there.
Ready to build new SaaS? Check out ont-run to ship API-first, MCP-ready applications from a single ontology.