Vibe coding does not replace SaaS. It splits it in two.
The takes go "vibe coding kills SaaS" or "no, it doesn't." Both miss the split that actually matters. The consumer-facing SaaS layer (small CRUD apps, dashboards, niche tools) is getting eaten. The infrastructure SaaS layer underneath (Postgres, email, analytics, repo hosting) is getting absorbed into the build moment. mk0r is the worked example: every session triggers four real backend API calls before your first prompt completes.
Direct answer, verified 2026-04-30
Partly. Vibe coding is replacing the consumer-facing SaaS layer (the small CRUD apps, internal dashboards, and niche tools that anyone can describe in one sentence) and absorbing the infrastructure SaaS layer (Postgres, email, analytics, repo hosting) into the build flow. The infrastructure SaaS still exists. It just provisions in seconds now, inside the build moment, instead of being a month-one onboarding tax.
Verifiable in src/core/service-provisioning.ts: 389 lines that POST to Neon, Resend, GitHub, and configure PostHog before any prompt is processed.
The frame I keep seeing on this is wrong
The two takes that show up everywhere on this topic both treat SaaS as one thing. Take A says vibe coding is going to replace it; you describe an app, you get an app, the small SaaS go away. Take B pushes back: the data model is hard, deliverability is hard, compliance is hard, vibe-coded apps are toys, SaaS is fine. They argue past each other because they are pointing at different layers.
There are at least two SaaS layers in any working product. There is the consumer-facing layer, the screens and forms a user actually opens. And there is the infrastructure layer, the Postgres and the deliverable email and the analytics pipeline that make those screens function. The first one is getting eaten. The second one is getting consumed faster than ever, by tools like mk0r.
What "eaten" looks like in practice
The categories that fall to vibe coding share a shape. Their moat was the product idea plus a small amount of CRUD plumbing, not data accumulation, not network effects, not regulated workflows. A team-of-five internal CRM. A booking page for a single solo coach. A vertical-specific lead tracker. A niche calculator that exports a PDF. A small habit tracker with three screens.
For these, the value proposition was almost entirely "someone described it once and built the screens." That description is now the prompt. The screens are now what comes back from the model. That category was always thin; AI describing-tools just made the thinness visible.
What the build moment actually pulls in
On mk0r, when you claim a new session, four backend services get provisioned before the agent has run a single tool call. The diagram below is what the session-claim hub fans out to. None of these are mocks. All four are real SaaS that bill on usage.
One session-claim, four backend SaaS
Open src/core/service-provisioning.ts line 297. The Resend, Neon, and GitHub calls are wrapped in a single Promise.allSettled. The PostHog assignment is synchronous because the project is shared and only an id needs to be allocated. The four ship together.
The four calls, in the order they happen
The provisioning step finishes well before your first prompt finishes streaming. Five things happen, then the agent gets the keys.
- 1
PostHog
App id assigned, line 82
- 2
Neon
Postgres project, pg_version 17
- 3
Resend
Audience and per-app key
- 4
GitHub
Private repo, line 233
- 5
/app/.env
Env vars injected, line 367
What this replaces, step for step
The thing that actually got replaced is not "a SaaS" in the singular. It is the week of glue work between having an idea and having a running app with a database, an email path, and a repo. Toggle below.
Six days, or seventy seconds
Day 1: name your idea. Day 2: pick a Postgres provider, sign up, create a project, copy a connection string, paste it into .env. Day 3: pick an email provider, get domain DNS approved, generate an API key, paste it into .env. Day 4: wire up analytics, copy a project key, set up a PostHog board, learn its event shape. Day 5: create a GitHub repo, push, set up CI. Day 6: maybe start writing the actual product.
- Five sign-ups, five dashboards to learn
- Five connection strings to keep straight
- Real product work starts in week two
The four backends, what each one is for
Auto-provisioned per mk0r session, before any prompt runs
Neon Postgres
A new project per session in aws-us-east-2 on Postgres 17. DATABASE_URL is in the VM's .env before your first prompt finishes streaming.
Resend
An audience named 'mk0r-<sessionSlug> Users' plus a sending-only API key, scoped to your app. Use it to send transactional email from the generated app.
PostHog
A unique appId tags every event from your session, so analytics from app A do not bleed into app B. VITE_POSTHOG_KEY and VITE_POSTHOG_APP_ID are wired in.
GitHub
A private repo named mk0r-<sessionSlug> on the m13v account. The session is a real git history, not a vendor-locked snapshot. Clone it and run npx vite locally.
The honest list of what is not getting replaced
If you read this far hoping for a "vibe coding kills SaaS" conclusion, the rest of the page is the disappointing part. Plenty of SaaS is fine.
- Anything with a data moat. Stripe's risk model, Plaid's bank coverage, Twilio's carrier graph. You consume them. You do not vibe-code them.
- Anything with real two-sided network effects. Marketplaces with liquidity, communication tools that live inside an organization, social products. The product is the graph, not the screens.
- Anything with regulated workflows. Healthcare data handling, financial reporting, payroll. The compliance evidence is the moat, the software is downstream of it.
- The infrastructure SaaS this very page is built on. Postgres-as-a-service, email deliverability, analytics pipelines, CDN edge nodes. Vibe-coded apps consume them; they do not replace them.
What is getting eaten is the layer in the middle, the layer where the only thing the vendor was doing was screens plus a small amount of CRUD on top of someone else's database. That layer was always thin. It is now describable in a sentence.
The shape of the new maker loop
The thing the existing pages on this topic miss is that the consumer SaaS that just got eaten and the infra SaaS that just got pulled in are connected. The consumer SaaS was eatable precisely because the infra SaaS underneath could be provisioned in seconds. If a Neon project still took an afternoon to set up and a Resend domain still took a week to verify, "one prompt and you have an app with a database and email" would be a lie. Because those calls finish in parallel before your first prompt streams, it is not.
The honest read on "vibe coding replace SaaS" is that it is not a substitution. It is a re-layering. The infra SaaS got faster, more API-shaped, and cheaper to compose. That made the consumer SaaS layer above it describable in a sentence. The vendors who own the infra got more powerful. The vendors who owned only the screens got commoditized. mk0r sits exactly on that seam.
Curious where the seam runs in your idea?
Show me the SaaS shape you are thinking about. We can usually tell in fifteen minutes whether it is the consumer layer (vibe-codable) or the infra layer (build vs. buy).
Frequently asked questions
Short answer: can vibe coding replace SaaS?
Partly, and not in the way most takes frame it. Vibe coding is replacing the consumer-facing SaaS layer, the small CRUD apps, dashboards, internal tools, and niche utilities you can describe in one sentence. It is absorbing, not replacing, the infrastructure SaaS layer (Postgres, email, analytics, repo hosting). Those still exist. The difference is they now provision in seconds inside the build flow, instead of being month-one onboarding tasks for a founder.
Which SaaS categories actually get eaten?
The ones where the moat was the product idea, not the infrastructure. Habit trackers, internal CRMs for small teams, simple booking pages, niche calculators, lightweight project boards, vertical-specific dashboards, lead scrapers, single-purpose forms with a database. Anything where a competent describing-engineer can sketch the data model in a paragraph and the screens in a sentence. The replacement is not 'no software'; it is 'this small SaaS is now one prompt'.
Which SaaS categories do not get eaten?
Anything where the moat is data accumulation (Stripe's risk model, Plaid's bank coverage, Salesforce's enterprise data graph), real network effects (Slack inside a company, marketplaces with two-sided liquidity), regulated workflows with bespoke compliance, or hard infrastructure (Postgres-as-a-service, email deliverability, CDN edge nodes). These are the SaaS that vibe-coded apps consume, not replace. mk0r consumes four of them per session.
What does mk0r actually pull in when I start a session?
Open src/core/service-provisioning.ts. The provisionServices() function at line 277 calls four real SaaS APIs: a Neon Postgres project (POST console.neon.tech/api/v2/projects with pg_version 17 in aws-us-east-2 at line 174), a Resend audience plus a per-app sending API key (POST api.resend.com/audiences at line 105 and POST api.resend.com/api-keys at line 126), a private GitHub repo (POST api.github.com/user/repos at line 233), and a PostHog app id (line 82). The Resend, Neon, and GitHub calls run in parallel via Promise.allSettled at line 297. The returned env vars (DATABASE_URL, RESEND_API_KEY, VITE_POSTHOG_KEY, GITHUB_REPO_URL) get written into the VM's /app/.env at line 367 before your first prompt is processed.
If the infra SaaS still exists, what changed?
Provisioning latency went from days to seconds, and it moved from a human task to a function call. Picking a Postgres provider, signing up, naming a project, copying a connection string, pasting it into an env file, those used to be the first afternoon of a side project. On mk0r they are five lines of fetch() that finish before your prompt is done streaming. The SaaS did not disappear. The friction it introduced into the maker loop did.
Is this an mk0r-specific take or does it generalize?
It generalizes. Cursor and Claude Code do not provision external services for you, but the pattern is the same: an agent loop that reaches into other SaaS to compose what you described. v0 deploys to Vercel. Replit Agent uses Replit's own database and hosting. Bolt and Lovable wire in Supabase. The shape is identical: vibe coding eats the surface, integrates the substrate. mk0r's choice is to make the substrate auto-provision per session instead of pointing you at someone else's onboarding flow.
Will the consumer SaaS that gets eaten just rebuild itself as 'AI-powered'?
Some will, and some already do. The honest test is: does the AI add a defensible reason this product exists, or is it lipstick? A small CRM that lets you describe rules in plain language is still a small CRM that an indie hacker can vibe-code in an afternoon. A vertical SaaS with five years of compliance evidence and twenty enterprise integrations is not. The 'AI inside' label does not move where the moat is.
What is the catch on the vibe-coded side?
Three things, honestly. First, generated apps have weak observability, you find bugs by trying things, not by reading errors. Second, schema migrations and data integrity are the part that is hard to vibe; you can describe a feature, you cannot wave at a corruption-safe migration. Third, the apps are usually mobile-first HTML/CSS/JS in mk0r's case, which is great for prototypes but not the right shape for a regulated payments flow or a kernel module. The categories that fall to vibe coding are the ones where these limits do not bite.