Oscar Hoang
Articles

· Product & Startups, build vs buy, SaaS, vibe coding, AI coding agents, indie hackers, email deliverability

Build vs Buy SaaS in the AI Era: What Is Still a Moat

A glowing castle made of code blocks surrounded by a drying moat, with a robot arm building a small copy of the castle beside it

AI coding agents have made it cheap to build your own version of a tool you used to pay for. That doesn't make every subscription a waste. It changes which ones are worth keeping, and which products are still worth selling.

This post starts from Maximilian Schwarzmüller's video "Software alone is no longer a moat". I checked his points against current data and the actual rules for things like bulk email.

The short answer: SaaS isn't dead. Software alone just stopped being a moat. AI agents make simple, low-stakes tools cheap to build in-house, so single-purpose SaaS is under pressure. Products whose value comes from data, compliance, deep integrations, or service beyond the code are still hard to replace. That's where I'd spend money, and what I'd want to build.

I care about this from both sides. I can build most small tools myself. I also build and sell small products of my own, like Kemisu (event software for speed dating hosts), DanceRecap and attndnce.

Is SaaS dead? What the 2026 data actually says

No. Companies are replacing some SaaS with their own builds. The data points to narrow tools. Core systems mostly stay.

Source Finding Caveat
McKinsey, State of AI 2026 32% of respondents say their organization decided against buying at least one software product or feature because it could be built in-house with agentic coding tools Survey of 1,719 participants in 97 countries, May to June 2026
Retool, 2026 Build vs Buy Report 35% have replaced at least one SaaS tool with a custom build; 78% expect to build more in 2026 Vendor survey of 817 builders, including Retool customers. Retool sells custom app building
Stack Overflow Developer Survey 2026 Of 13,338 people answering the in-house building question, 18.6% are replacing paid vendors, vs 77.3% building small scripts and automations Opt-in survey of Stack Overflow users
Gartner, July 2026 Up to $234B of enterprise application spend exposed to "agentic arbitrage" through 2030, roughly 20% of enterprise application SaaS spend Forecast, not measured spend

The trend is real and growing. Still, replacing a paid vendor is a minority activity. Gartner calls the "SaaSpocalypse" "less an apocalypse and more of a metamorphosis." Max says the trend is accelerating. That's his read. None of these sources measure acceleration over time.

Why building your own got cheap, and what still costs money

The first build got cheap. Maintenance didn't.

The build was always the smaller part of the bill. A long-standing estimate, cited in the arXiv paper "The Buy-or-Build Decision, Revisited", puts operations and maintenance at 60 to 80% of lifecycle cost. It comes from work published between 1980 and 2002, so treat it as a heuristic. The paper's point holds: that share "does not disappear simply because the development share shrinks."

Max quotes a line you sometimes read: "vibe coding software is fun; maintaining is not." The more important the software, the more that hurts.

What is safe to vibe code (and what isn't)

Vibe code tools where a failure is visible, cheap and only hurts you. Anything that touches other people's inboxes, money, logins or regulated data, pay for or engineer carefully.

Max's example is a background remover he vibe coded for his thumbnails. If it goes wrong, he sees it and fixes it. Nobody else is affected.

Tool type Example Who gets hurt if it breaks? Verdict
Personal utility Thumbnail background remover, file renamer, one-off scripts Only you, and you see it immediately Vibe code it
Internal dashboard (read-only) Metrics view over your own database Your team, mildly Vibe code, add basic auth
Small team workflow Lightweight task tracker Your team; data loss is the risk Build with real review and backups, or buy
Logins for outsiders Customer portal, user accounts Your users; access-control bugs Use a proven auth provider
Payments and billing Checkout, subscriptions, webhooks Customers and your revenue Buy (Stripe or similar) and review the integration
Email to other people Newsletter, transactional email Your audience and your sender reputation Use an email provider; never skip unsubscribe or SPF, DKIM and DMARC
Regulated data Health, finance, legal records Users, plus legal liability Buy, or build only with real expertise
Systems of record CRM, ERP, accounting The whole business Usually buy; build your own tools around it

The security risk has been measured. A 2026 preprint, "Understanding the (In)Security of Vibe-Coded Applications", audited 200 publicly deployed apps built mostly by Claude Code or Lovable. It found at least one vulnerability in 91% of them, and 65.77% of the findings were rated Critical or High. Broken access control, injection and authentication failures were the most common. It's a preprint and hasn't been peer reviewed.

Why email is Max's example of what not to vibe code

Max's companies did replace a paid email-sending service. He's a developer, though, and his warning is about vibe coding it. Even with AWS SES, he says, setup "is more than just one click." Here's what that involves:

  • The SES sandbox. Every new SES account starts in a sandbox. You can send to verified recipients only, at most 200 messages per 24 hours, until AWS approves production access.
  • Domain verification. DKIM records in DNS (up to 72 hours to propagate), plus a DMARC policy.
  • Gmail and Yahoo. Gmail treats you as a bulk sender at around 5,000 messages a day to personal accounts. Yahoo publishes no threshold. Bulk senders need SPF, DKIM and DMARC, one-click unsubscribe on marketing mail plus a visible link, and a spam rate below 0.3%.
  • RFC 8058. One HTTPS link in List-Unsubscribe, List-Unsubscribe-Post: List-Unsubscribe=One-Click, and a DKIM signature covering both.
  • CAN-SPAM. US commercial email needs a working opt-out, honored within 10 business days, and a valid postal address.

So Max's example of forgetting to build unsubscribe is a compliance problem, not just a missing feature. Here are the headers with the AWS SDK for JavaScript v3 (placeholders only; nothing is sent until you call it with real credentials):

import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2";

const ses = new SESv2Client({ region: process.env.AWS_REGION ?? "us-east-1" });

// Opaque token that identifies the recipient and the list (RFC 8058).
const unsubscribeUrl = `https://example.com/unsubscribe/${"opaque-token"}`;

const command = new SendEmailCommand({
  FromEmailAddress: "newsletter@example.com", // must be a verified identity
  Destination: { ToAddresses: ["reader@example.com"] },
  Content: {
    Simple: {
      Subject: { Data: "This week's issue", Charset: "UTF-8" },
      Body: {
        Text: {
          Data: `Hi there.\n\nUnsubscribe: ${unsubscribeUrl}`,
          Charset: "UTF-8",
        },
        Html: {
          Data: `<p>Hi there.</p><p><a href="${unsubscribeUrl}">Unsubscribe</a></p>`,
          Charset: "UTF-8",
        },
      },
      Headers: [
        { Name: "List-Unsubscribe", Value: `<${unsubscribeUrl}>` },
        { Name: "List-Unsubscribe-Post", Value: "List-Unsubscribe=One-Click" },
      ],
    },
  },
});

export async function sendIssue() {
  const result = await ses.send(command);
  console.log(result.MessageId);
}

The headers are the easy part. You still need an endpoint that accepts the POST without redirecting and removes the subscriber quickly. Or pass ListManagementOptions with a contact list and topic, and SES adds the headers and handles unsubscribes itself. Either way, check the h= list in the DKIM-Signature of a test send to confirm both headers are signed. I found no AWS doc that guarantees it.

A build vs buy checklist

Score the tool with the questions below. Any "yes" in the second block should push you toward buying.

Leans build:

  • Is it low stakes if it breaks, and will I notice right away?
  • Does it only affect me or my team, not customers?
  • Do I use a small fraction of the paid tool's features?
  • Is the subscription meaningful money compared with my build and maintenance time?
  • Is it close to my core skills, so maintaining it is cheap for me?

Leans buy (any yes is a strong signal):

  • Does it send email, move money, handle logins, or store regulated or personal data?
  • Would a failure hurt other people or my reputation?
  • Does the vendor's value come from data, compliance work, deliverability, support or integrations I can't replicate?
  • Would I be the only person who understands the code if it breaks at 2 a.m.?
  • Does it need ongoing work to stay compliant or working?

Final check: if I build it, who maintains it in a year, and what is that worth per month?

A hypothetical worked example. Say you're weighing a newsletter tool against your own build on SES. You may use only a fraction of its features, and the sending code is short. The buy block lights up anyway. It emails other people, a bad send hurts your reputation, deliverability is much of what the vendor sells, and the rules move (Gmail began ramping up enforcement in November 2025). Without email expertise, that's a buy. Max's background remover is the opposite. Every build answer is yes and every buy answer is no.

The moats that still hold

Data you can't easily get, compliance and legal complexity, and value beyond the software itself.

As Max puts it, in those products "you're not really paying for the software there." I'd read "value beyond the software" broadly: support, uptime promises, sender reputation, deep integrations and trust. I'd also add distribution, an audience that already knows you. That one is my addition. Max didn't list it.

If the only protection was that the product was hard to build, it's mostly gone.

Why big companies keep SAP and Salesforce (mostly)

Core systems mostly stay, because they're wired into everything and replacing them is risky. The edges get rebuilt.

Max's view is that SAP or Salesforce are so deeply integrated that companies keep paying. He says that may change over ten years, but "nobody can look into the future."

There are counterexamples. PYMNTS, citing The Information, reports that five companies with 20 to 70 staff replaced Salesforce or HubSpot with AI-built apps, cutting software costs 40% to 80%. It also reports that Sanofi is cutting 80% of its ServiceNow usage. These are secondhand reports, so treat them as anecdotes. Big companies also have the most capacity to build. McKinsey says about two in ten respondents report scaling software coding agents, and 31 percent at larger enterprises.

What this means for indie hackers

It's harder, especially if you sell to developers. They're the buyers most able to rebuild your product.

Max makes this point, and I agree. His cautionary example is AI headshot and cartoon services, which he thinks worked well a year or two ago and are under pressure now. The pieces check out. Apple's Image Playground is built into iOS, and OpenAI says free ChatGPT users can create images within usage limits. Whether those businesses are shrinking is his opinion. I found no data.

If I started a product now, I'd pick a problem where I bring something beyond the code: data, a fiddly or regulated workflow, an audience, or ongoing service.

What it means for developers (and your employer)

Look at whether your company sells easily replaceable software. Treat that as a planning signal. It's no reason to quit tomorrow.

Max is careful here. A job beats no job, he says, but a replaceable product means being cautious about your planning. He also predicts less hand-written code, and code review that no longer means reading every line. He hedges both.

Key takeaways

  • SaaS isn't dead. Single-purpose tools are under pressure, and core systems mostly stay.
  • The first build got cheap. Maintenance didn't.
  • Vibe code tools where failure is visible and only hurts you.
  • Buy, or engineer carefully, anything touching email, money, logins or regulated data.
  • The moats that hold are data, compliance, integrations, service and distribution.

FAQ

Is SaaS dead because of AI? No. Gartner calls the shift "less an apocalypse and more of a metamorphosis." In Stack Overflow's opt-in 2026 survey, only 18.6% of the 13,338 people who answered the in-house building question picked replacing paid vendors.

Should I build my own tools instead of paying for SaaS? Build when it's low stakes, only affects you, and you use a fraction of the paid product. Buy when it touches customers, money, email or regulated data.

What shouldn't you vibe code? Authentication, payments, outbound email, and anything holding personal or regulated data. A 2026 preprint found at least one vulnerability in 91% of 200 deployed vibe-coded apps it audited.

What moats still work for SaaS in the AI era? Hard-to-get data, compliance, deep integrations, and value beyond the code such as support, trust and distribution.

Is it still worth building a micro SaaS as an indie hacker? I think so, but it's harder. Pick problems where you bring data, a fiddly workflow, an audience or ongoing service. A utility buyers can rebuild in an afternoon won't hold up.

Sources