Whether you're looking for an angel investor, a growth advisor, or just want to connect — I'm always open to great ideas.
Get in TouchAI coding agents like Cursor and Claude Code are letting enterprises build custom tools in days, not months. This guide covers which SaaS categories face existential build-vs-buy risk, which are safe, and how to defend your product.
AI, startups & growth insights. No spam.
TL;DR: The build vs buy calculus that has driven SaaS growth for fifteen years is breaking. AI coding agents — Cursor, Claude Code, GitHub Copilot Workspace — have collapsed the cost and time to build custom software by 80-90%. An intern with a $20/month Cursor subscription now builds what used to require a $50K/year SaaS contract. This is not a future threat. It is happening in procurement meetings right now. This guide covers which SaaS categories face existential risk, which are safe, what the "good enough" trap looks like at scale, and the exact strategic responses that work. If you sell software to enterprises or mid-market companies, this is the most urgent thing you can read this quarter.
For the better part of twenty years, the SaaS pitch was simple and it worked: building custom software is slow, expensive, and painful to maintain. Buying a SaaS product gives you a working solution today, a team maintaining it for you, and a product that improves every month. The math was easy.
A mid-market company in 2018 that wanted an internal employee onboarding portal had three options: hire two engineers for six months ($150K+ all-in), buy an HR SaaS tool for $30K/year, or cobble together something in SharePoint that no one would use. Buying was obviously correct.
The key inputs to that calculation were:
Engineering cost. Senior engineers in 2018 cost $150-200K in salary, often more with benefits and overhead. A six-month project meant a $75-100K minimum for the build, before QA, deployment, and maintenance.
Build time. A custom CRUD application — user management, a data model, a UI, some reporting — took 2-4 months of focused engineering time. That timeline was the reality given the state of frameworks, the learning curve, and the complexity of deployment.
Maintenance burden. A custom-built tool does not maintain itself. When Node.js releases a security patch, someone has to apply it. When you add a new department, someone has to extend the data model. When the CEO wants a new report, someone has to write it. That ongoing maintenance load was real and frequently underestimated.
Reliability. A SaaS vendor has a 24/7 operations team, an SLA, status pages, and redundancy built into the infrastructure. A custom-built internal tool has whoever built it, and that person has other priorities.
These four factors made SaaS the obvious choice for most companies for most problems. The entire $700B SaaS market was built on this structural advantage.
That structural advantage is eroding — and in certain categories, it has already flipped.
To understand the scale of the shift, you need to understand what AI coding agents actually do today, not what people imagine they do.
Cursor is not autocomplete. It is not even smart autocomplete. In agent mode, you describe a feature in plain English, and Cursor reads your entire codebase, plans the implementation across all affected files, writes the changes, runs the tests, debugs the failures, and marks the task done. The human reviews the output, tests the result, and iterates on the description if something is wrong.
Claude Code operates similarly but runs in the terminal with a large context window that can hold most mid-sized codebases simultaneously. You tell it to "add Stripe subscription billing with a free tier and two paid plans, using the existing PostgreSQL schema," and an hour later you have the Stripe integration, webhook handlers, database migration, API endpoints, and UI components across eight files.
GitHub Copilot Workspace takes a GitHub issue, plans the implementation, and generates a pull request. You review and merge.
The practical result of these tools is that the time to build a functional custom web application has compressed from months to days, and from days to hours for well-scoped features.
Here is a concrete benchmark comparison that matters for the build vs buy calculation:
2020: Build a custom internal employee directory with search, org chart, profile editing, and admin controls. Realistic estimate: 6-8 weeks for a skilled full-stack engineer.
2024 with Copilot: Same feature set, 2-3 weeks. AI handles the boilerplate; the engineer architects and reviews.
2026 with Claude Code / Cursor Agent: Same feature set, 2-4 days. A mid-level engineer describes what they want, the agent builds it, the engineer tests and iterates. A senior engineer can do it in an afternoon.
That compression — from 8 weeks to 2-4 days — is not a marginal improvement. It is a categorical change in the economics of custom software.
The other dimension that changed is who can build. The "one intern with Cursor" scenario is not a startup myth. I have seen it repeatedly: a company's non-technical product manager learns enough to direct Claude Code effectively and ships a functional internal tool. A data analyst builds a custom dashboard tool that talks directly to their warehouse without involving engineering at all. A customer success manager builds a customer health scoring tool by describing it in Cursor and iterating for a week.
The democratization of building is raising the quality and capability ceiling for internal software far above where it was in 2020.
Let me run the numbers that are now appearing in enterprise procurement conversations.
The old calculation (2020):
The new calculation (2026):
The key variables that changed:
The third factor is particularly important. SaaS vendors, flush with the growth of the past decade, kept raising prices. Seat-based pricing multiplied as companies grew. Add-on features became separate SKUs. What cost $2,000/month in 2020 now costs $5,000/month for the same seats with mandatory add-ons.
That pricing behavior is now meeting a build alternative that costs a fraction of what it used to. The collision of rising SaaS prices and falling build costs is the structural disruption that SaaS founders need to take seriously.
Not all SaaS is equally threatened. The risk varies dramatically by category. Here is how I score it:
| Category | Vulnerability | Primary Reason | Timeline |
|---|---|---|---|
| Internal dashboards / BI tools | Critical | CRUD + visualization = AI's sweet spot | Now |
| Internal portals / knowledge bases | Critical | Pure information architecture, no network effects | Now |
| Simple automation / workflow builders | High | Code agents do this natively | 6-12 months |
| HR onboarding tools | High | Mostly forms + workflows + reporting | 6-18 months |
| Project management (SMB) | High | Linear/Notion replacement is 1 weekend build | Now |
| CRM (SMB/mid-market) | Moderate-High | Data model is complex but not moated | 12-24 months |
| Email marketing platforms | Moderate | Infrastructure complex; sending reputation matters | 24-36 months |
| Vertical SaaS (healthcare, legal) | Low-Moderate | Compliance requirements create defensibility | 36-48 months |
| Security / identity (SSO, PAM) | Low | Trust, compliance, and certification moats | 48+ months |
| Infrastructure (cloud, databases) | Very Low | Commodity infrastructure is infrastructure | Not a factor |
| Payments / billing infrastructure | Very Low | Regulatory moats + trust requirements | Not a factor |
| Data warehouse / lakehouse | Very Low | Performance engineering at scale is irreplaceable | Not a factor |
| ML platform / AI infrastructure | Very Low | Running models requires specialization | Not a factor |
The pattern is clear: vulnerability correlates directly with how much of the product is CRUD logic, simple workflow automation, or information architecture — the exact things AI coding agents do extremely well. Safety correlates with regulatory requirements, data-at-scale performance engineering, trust requirements, and genuine network effects where the product's value depends on other users being on the same platform.
Let me be specific about the category that faces the most immediate threat. I am calling it "CRUD and dashboard" software, and it covers a huge portion of the SaaS market.
CRUD stands for Create, Read, Update, Delete — the four basic operations of any database-backed application. An enormous amount of business software is fundamentally: a database with a nice UI, some filtering and searching, some reporting, some user permissions, and maybe some integrations. That description fits:
Every single one of these is something a competent engineer can now build with Claude Code in 2-3 days. A well-specified prompt like "build an internal vendor management system with vendor profiles, contract tracking, renewal alerts, and an admin panel, using PostgreSQL and Next.js" produces 80-90% of a working application in hours. The remaining 10-20% is iteration, testing, and UI polish — another day or two.
The SaaS tools in this category are charging $20-100/seat/month for applications that now cost a few thousand dollars to build and maintain internally. When a 100-person company is paying $5,000/month for an internal wiki tool, the build conversation gets serious.
Notion is a fascinating case study here. It is an excellent product. But the core value proposition — a flexible, block-based workspace for notes, databases, and project tracking — is now something a team can replicate with basic functionality in a weekend. The reason companies still use Notion is not that they cannot build an alternative. It is that Notion has already accumulated all their content, has become embedded in their workflows, and the switching cost is high. That switching cost is the actual product at this point, not the technology.
The threat to new SaaS companies in this category is more acute than to incumbents. A well-established CRUD SaaS tool has the switching cost moat. A new entrant trying to sell against Notion, Airtable, or Asana is fighting a two-front war: the incumbents on one side and AI-built custom tools on the other.
The second most vulnerable category is automation and workflow software — tools like Zapier, Make, n8n, and their equivalents.
This category is interesting because AI coding agents and no-code automation tools are serving similar use cases from different angles. The user who used to open Zapier to connect Slack to their CRM can now open Cursor, describe the integration, and have actual Node.js or Python code running in 30 minutes. The custom code is more flexible, more debuggable, and free to run on their own infrastructure.
The specific threat is to the upper half of these tools' user bases — the power users who build multi-step automations with conditional logic, data transformations, and error handling. Those users are increasingly moving to custom code. The lower half — the users building simple two-step integrations with no coding experience — remain as customers.
What this means is gradual revenue erosion rather than sudden collapse. Automation tools are losing their most valuable customers (power users who pay the most and expand within the platform) while retaining their most price-sensitive customers. The unit economics of the category are getting worse even if total user counts stay flat.
However, the automation platforms that have invested in building infrastructure — proprietary connectors, API management, retry logic, authentication handling for hundreds of integrations — have more defensibility than they appear. The actual connectors in Zapier (5,000+ app integrations) took years to build and maintain. Writing a custom integration with Cursor still requires the API documentation, the authentication flow, the error handling, and the maintenance. Zapier has pre-built and battle-tested all of that.
The threat is real but the moat is also real. The question is whether they can charge enough for the infrastructure value to compensate for losing power users to custom code.
Several categories are structurally protected from the build vs buy flip. Understanding why helps you position a product in these spaces — or understand what it would take to threaten incumbents.
Compliance software — SOC 2 automation, GDPR compliance, ISO certification tracking — benefits from regulatory moats that are impossible to replicate quickly. A company using Vanta or Drata is not just buying software. They are buying a product that has pre-built the evidence collection workflows for specific frameworks, has integrations with the specific cloud providers and services that auditors accept, and — critically — has the vendor relationship trust that auditors extend to known platforms.
An auditor accepting evidence collected by Vanta is qualitatively different from an auditor accepting the same data collected by a custom-built tool they have never seen. That trust is not technical — it is relational and institutional. An AI-built compliance tracker is not a Vanta replacement because the product is not the software, it is the compliance workflow credibility.
Security software (SIEM, PAM, endpoint detection, identity management) has similar characteristics plus performance requirements. Running a Palo Alto Networks SIEM alternative in-house requires not just the software but the threat intelligence feeds, the detection rules honed on millions of real attacks, and the 24/7 response infrastructure. No intern with Cursor is building that.
Okta's SSO product is technically replaceable — open-source alternatives like Authentik exist and work well. But replacing Okta in an enterprise means migrating hundreds of application integrations, handling the compliance audit trails for SOX and HIPAA, and maintaining a security-critical piece of infrastructure. The decision is not "can we build a better SSO?" The decision is "is the risk of this migration worth the cost savings?" For most enterprises, the answer is no.
Data warehouse and analytics infrastructure — Snowflake, Databricks, BigQuery — is not threatened by build vs buy dynamics at all. These platforms represent 10-15 years of performance engineering: query optimization, storage formats, distributed compute, and the operational expertise to run petabyte-scale systems reliably. No team is building a custom Snowflake replacement in Cursor.
The vertical SaaS plays in healthcare, legal, construction, and manufacturing also benefit from compliance-adjacent defensibility. A custom-built healthcare data management tool is not just a CRUD app — it requires HIPAA compliance, specific HL7/FHIR data model standards, integration with EHR systems that have their own certification requirements, and BAA agreements with every vendor in the stack. The regulatory complexity creates a meaningful barrier.
Here is the argument SaaS sales teams are deploying, and it has merit: the AI-built custom tool that looks great in the demo often fails badly at scale.
This is the "good enough trap." A company's engineering team builds a custom internal tool with Claude Code in a week. It works perfectly for the first 20 users. The demo to the exec team is impressive. The project is considered a success, and the SaaS contract is cancelled.
Six months later, the tool has 200 users, and the problems begin.
Performance. The database queries that worked fine with 500 records are timing out with 50,000 records. Nobody added indexes. Nobody thought about pagination. The UI that loaded in 200ms for a small dataset is loading in 8 seconds for the real one.
Security. The authentication was implemented quickly and it works, but nobody audited it. There is a SQL injection vulnerability in the search feature. The admin panel has no rate limiting. The logs have no audit trail. A compliance audit arrives and the tool fails on four controls.
Maintenance. The engineer who built it left the company. The documentation is sparse. The next engineer who looks at the codebase spends a week understanding it before they can add the feature the CEO wants.
Feature gaps. The initial build covered 80% of the use case. The remaining 20% — edge cases, power user features, integrations with other tools — keeps trickling in as feature requests. The internal tool becomes a product backlog, competing with customer-facing work for engineering time.
Reliability. The production database is running on a single VM. When it goes down at 10 PM on a Thursday, nobody is on call because this is "just an internal tool."
This failure pattern is real and it is why build vs buy historically reverted to buy after every wave of "we will just build it ourselves" enthusiasm. The SaaS vendor's moat was never just the software — it was the operations, the reliability, the maintenance, and the engineering depth that stood behind it.
The question in 2026 is whether AI coding agents also close these gaps. Partially, yes. Claude Code will suggest adding indexes when you describe performance problems. It will flag security issues in code review. It will help onboard the next engineer by explaining the codebase. But it does not fix the organizational problem of who owns the tool, who is on call for it, and whose job it is to keep it secure and updated.
The companies most likely to win the build argument are the ones that solve the organizational problem alongside the technical one — clear ownership, documentation practices, a maintenance budget, and an upgrade cadence. The companies that build impulsively without those structures end up proving the SaaS vendor's point.
If you work in enterprise IT, the current moment feels familiar. You have seen this before.
In the 2000s, the shadow IT era, individual teams started using cloud tools — Dropbox, Gmail, Trello, Slack — without waiting for IT approval. These tools were consumer-quality, cheap or free, and infinitely faster to deploy than the enterprise alternatives. IT departments tried to block them. They failed. Eventually, the enterprise versions of these tools (Slack Enterprise Grid, Dropbox Business, Google Workspace) became the official standard, and the shadow IT tools became the official tools.
The shadow IT wave was driven by: consumer tools reaching enterprise-quality, radical cost advantages (free vs. six-figure enterprise contracts), and the consumerization of expectations (employees who used great consumer tools refused to tolerate bad enterprise software).
The AI-built custom tool wave has the same structure. Individual teams and technical employees are building custom tools without procurement approval, outside the IT governance process, and outside the vendor management process. The tools are good enough for their immediate use case. The cost is almost nothing. The IT department is going to find out six months later when the tool has 50 users and the engineer who built it is presenting it in a business review meeting.
The twist this time is that these are not commercial tools being adopted without approval — they are bespoke internal builds with no vendor to add to the approved list. The shadow IT governance frameworks enterprises built after the 2000s wave (vendor risk management, SaaS procurement policies, security reviews) do not apply cleanly to an internal tool built by an intern with Cursor. There is no vendor to review. The IT security team has to evaluate code, not a vendor questionnaire.
This creates a new governance problem that enterprises are just starting to grapple with. Who approves an AI-built internal tool for production use? What security review does it go through? What happens when the builder leaves? What are the data handling requirements?
The companies that are getting ahead of this are creating "citizen developer" governance frameworks — fast-track review processes for AI-built internal tools that impose minimum security and documentation requirements without the full enterprise procurement overhead. Gartner predicted in 2024 that by 2026, 80% of technology products and services will be built by non-traditional technologists. That prediction is on track.
The opportunity for SaaS companies in this dynamic: be the governance layer. If you can position your product as the approved platform on which citizen developers build, you capture the wave rather than getting displaced by it.
I want to give you concrete examples rather than abstractions. These are patterns I have seen directly or through conversations with founders in the past twelve months.
The project management displacement. A 150-person tech company was evaluating a new project management tool at $8,500/month. During the evaluation, their lead engineer built a custom alternative in Cursor over a long weekend — it connected directly to their existing GitHub repos, Slack notifications, and Postgres database. Not as polished as the commercial tool, but handling 90% of their use cases and deeply integrated with their existing stack. They cancelled the evaluation. The SaaS vendor never knew why they lost the deal.
The internal dashboard loss. A B2B analytics SaaS was pitching a mid-market e-commerce company at $36,000/year. The prospect's data team built a custom dashboard tool using their existing BigQuery data and a Next.js frontend over three weeks. The custom tool did exactly what they needed and nothing they did not. The SaaS deal died in legal review — not because legal blocked it, but because the data team shipped their alternative first and the urgency was gone.
The HR tool replacement. A 400-person company was paying $60,000/year for an HR onboarding and documentation platform. After a pricing increase to $84,000 at renewal, the HR team went to engineering and asked them to evaluate a rebuild. One engineer spent two months building a replacement with Claude Code. The result handles all core use cases and costs $0 in licensing. The company took the $84K and put it toward engineering headcount.
These stories share a pattern: the build decision was not made because the SaaS product was bad. It was made because the cost-to-capability ratio of building crossed a threshold where the conversation became rational. And once an internal team shipped the first version, the deal was effectively dead — the organizational momentum shifted.
What SaaS vendors do not see is how often they lose deals before a single conversation happens. A prospect puts out a build vs buy RFP internally, the engineering team responds with "we can build this in three weeks," and the vendor is never contacted. The lost deal never appears in the CRM.
The response cannot be "price lower." Competing on price against a cost base of nearly zero is a race to the bottom you cannot win. The response must be about widening the gap between what you offer and what an internal build can reasonably deliver.
Move from feature selling to outcome selling. Feature selling asks: "Does our tool have X, Y, and Z?" An internal build can usually match features. Outcome selling asks: "What specific business result does our tool produce that you cannot achieve otherwise?" The outcome has to be something the internal build genuinely cannot deliver — not because the features are absent, but because the outcome requires the network, the data, or the operational infrastructure that you have and they do not.
Salesforce sells not just a CRM but access to the Salesforce ecosystem — AppExchange, the partner network, the consultants who know the platform, the benchmarking data across thousands of companies. An internal CRM build has none of that. That ecosystem is the product.
Lead with network effects. If your product's value increases as more companies use it, no internal build can replicate that. Benchmarking tools that show you how you compare to similar companies require the comparison cohort. Supply chain software that helps you find new suppliers requires the supplier network. HR tools that provide salary benchmarks require the salary data from thousands of companies. These are genuine network effects that cannot be built internally.
Lead with data moats. If your product produces unique data — industry benchmarks, behavioral analytics, predictive models trained on your entire customer base — the build argument collapses. Your competitor cannot tell a prospect "you can build this yourself" if "this" includes training a model on data from 10,000 similar companies.
Lead with compliance. If your product comes pre-certified, pre-audited, and pre-accepted by the auditors and regulators your customers answer to, that certification cannot be built internally. Sell the certification, not just the software.
Lead with integration depth. An internal build starts with zero integrations. Your product has 200 pre-built integrations, battle-tested over years, with authentication handling, rate limit management, and error recovery built in. The real cost of building those integrations — not the MVP but the production-ready versions that handle edge cases — is enormous.
Going deeper on the three structural defenses that actually work:
Data moats are the most powerful. A data moat exists when your product accumulates data that improves with scale and cannot be replicated from scratch. Spotify's recommendation engine is a data moat — not because the algorithm is secret, but because it was trained on the listening behavior of 600 million users over fifteen years. LinkedIn's economic graph is a data moat. Veeva's pharmaceutical compliance database is a data moat.
For SaaS companies, the question is: does your product get smarter as more customers use it? If yes, that intelligence cannot be replicated by a new internal build. If no — if your product is the same quality for a 1-user free tier as for a 10,000-seat enterprise — you do not have a data moat and you need to build one.
Network effects are real but rarer than vendors claim. A true network effect means each new user makes the product more valuable for existing users — not just that you have a large customer base. Slack has a network effect: each person who joins a Slack workspace makes the workspace more valuable. HubSpot has a weak network effect at best: more HubSpot users does not make your HubSpot instance more useful.
Switching costs are often underestimated by SaaS vendors. They are also the most ethically complex defense because they can be either legitimate (the product genuinely knows your data better after years of use) or manufactured (data export is deliberately hard, contract terms are punitive). Legitimate switching costs come from: deep data accumulation, embedded workflows that would require significant retraining to change, integration footprints that took years to deploy, and institutional knowledge baked into the product configuration.
The AI agents replacing SaaS conversation focuses on whether agents can replicate features. It rarely focuses on switching costs, which are the actual defense. A company does not abandon a CRM with 7 years of customer history just because an intern can build a new CRM UI in a week. They would have to migrate that history, rebuild all the automations, retrain the sales team, and re-establish all the integrations. That is a six-month project costing hundreds of thousands of dollars. That is the switching cost moat, and it is real.
The implication for new SaaS products: build switching costs intentionally from day one. Design for data accumulation. Make your product the system of record for something that matters. Create integrations that become hard to untangle. This is not about being hostile to customers — it is about being so deeply embedded in their workflows that the build alternative becomes obviously inferior to the cost of migration.
I want to give the counter-argument its full due because it has real merit.
History says this wave will recede. Every ten years, a new wave of democratized building tools prompts the same "why buy when you can build?" conversation. In the early 2000s, it was open source — Linux, MySQL, Apache. In the 2010s, it was no-code and low-code. In every case, the wave crested, and SaaS growth continued.
The reason is always the same: the gap between "can build" and "should build" remains large even when the cost to build falls. Open source made the software free — but operating it, securing it, and maintaining it still cost money and attention. Low-code made building faster — but the resulting tools still needed governance, support, and maintenance. AI coding agents are making building radically faster, but they are not eliminating the organizational cost of owning custom software.
The total cost of ownership calculation almost always favors buy when done honestly. The build cost is visible and often dramatic. The ongoing cost of custom software — maintenance, security patches, support, documentation, onboarding new team members, extending the tool for new use cases — is invisible at build time and almost always underestimated.
A company that builds an internal tool with Cursor in two weeks will spend the next two years incrementally improving, maintaining, and supporting that tool. The $8,000 build becomes $30,000 in total investment over two years, which competes more evenly with the SaaS alternative they could have bought.
The quality ceiling matters. AI-built tools in 2026 are impressive, but they are not Salesforce, Notion, or Figma. Those products represent thousands of engineer-years of investment — not just in features but in performance, reliability, accessibility, internationalization, and the thousand edge cases that make a product feel polished rather than prototype-level. For many use cases, "good enough" genuinely is good enough. But for the use cases where quality matters — customer-facing tools, high-stakes workflows, tools used by hundreds of people with varying technical sophistication — the gap between an AI-built MVP and a mature SaaS product remains large.
The talent and attention cost is real. Every internal tool your engineering team builds and owns is something they are not building for customers. For companies whose competitive advantage is their product, not their internal tooling, the opportunity cost of maintaining custom tools is genuine. SaaS vendors often undersell this argument: "your engineers should be building your product, not your tooling."
The honest conclusion is that the build vs buy shift is real and significant, but the total addressable threat is smaller than the most alarmist analysis suggests. The categories that face genuine existential risk are specific. The categories that are structurally protected are also specific. The job of a SaaS founder is to know which category they are in and respond accordingly.
Looking across the market, certain patterns emerge in where build is winning procurement debates.
The trigger is almost always price. Build becomes the active alternative when renewal pricing increases sharply, when seat-based pricing becomes painful as the company grows, or when an add-on feature that was "free" becomes a separate, expensive SKU. Price increases of 20-30% are now reliably triggering build evaluations in mid-market companies.
The second trigger is control. Enterprises are increasingly wary of data leaving their perimeter, of being subject to a SaaS vendor's data practices, or of losing access to their own data when a vendor is acquired or shuts down. An internal build, by definition, keeps data internal.
The third trigger is integration friction. When a SaaS tool does not integrate cleanly with the rest of the stack, the team that needs the integration evaluates building from scratch. The cost of the SaaS tool plus the cost of the hacky integration is often higher than a custom build that has the integration as a first-class feature.
Lenny Rachitsky noted in a 2025 newsletter that the most common complaint he hears from growth operators is not "the SaaS tool does not have the feature I need." It is "the SaaS tool does not integrate with the rest of our stack in the way I need." Integration quality is now a primary competitive dimension, not a secondary one.
The companies most likely to lose deals to internal builds have these characteristics in common:
Here is the framework I would use if I were running a SaaS company in a vulnerable category today.
Step 1: Honestly assess your category vulnerability. Use the risk matrix above. Ask: if a senior engineer spent two weeks with Claude Code, what percentage of our core value proposition could they replicate? If the answer is above 50%, you are in a vulnerable category and need a strategic response.
Step 2: Audit your actual moats. What does your product have that cannot be replicated in a custom build? Be brutally honest. List only things that are genuinely hard to replicate: proprietary data, compliance certifications, network effects, specific integrations that required dedicated engineering investment, and operational infrastructure.
Step 3: Redirect marketing spend to moat communication. If your moat is compliance certification, that needs to be on your homepage, in your sales deck, and in your renewal conversations. If your moat is network effects or data benchmarking, show the data. If your moat is integration depth, quantify it — "200+ pre-built integrations, saving the average team 6 months of integration work."
Step 4: Build a migration cost calculator. The best defense against "we can build this" is a realistic honest assessment of what building and maintaining it actually costs. Build a public ROI calculator that includes not just the build cost but the ongoing maintenance, the support cost, the opportunity cost of engineering time, and the security and compliance burden. Many companies cancel their build projects when they honestly calculate the 3-year TCO.
Step 5: Shift renewal conversations to outcome metrics. If you are renewing at a price increase, you need to come with data on outcomes achieved — not features used. "Your team saved 4,200 hours of manual work, avoided 3 compliance incidents, and processed 2.3 million records in the last year" is a renewal conversation. "Here are the features we added last quarter" is not.
Step 6: Consider the citizen developer opportunity. If internal builds are happening anyway in your customer segment, can you be the platform they build on? Salesforce did this with Flow and Apex. Notion did it with their API. If your product becomes the database and infrastructure layer, and customers build their custom UI and workflows on top of you, the build vs buy dynamic becomes a tailwind instead of a headwind.
Step 7: Evaluate the product defensibility of your SaaS product with fresh eyes. Pretend you are a well-funded competitor launching today. What would you build differently? Where is your current product weakest? The answers tell you where AI-built custom tools will attack first.
Q: Is the build vs buy shift happening more in enterprise or mid-market?
It is happening most aggressively in mid-market (100-1,000 employees) right now. Enterprise has longer contract cycles, more governance overhead, and higher switching costs that slow the dynamic. Very small companies (under 50 employees) often lack the engineering resources to build and maintain custom tools. Mid-market has the most exposure: large enough to have meaningful SaaS bills ($50K-500K/year in aggregate) and engineering teams capable of executing builds, but not yet locked into multi-year enterprise agreements with deep switching costs.
Q: Which specific SaaS categories should I avoid building in 2026?
Any SaaS product that is primarily a CRUD application with a dashboard and some reporting is hard to justify as a new venture. The competitive argument you need to make — "why pay us instead of building this in Cursor?" — is now the first question in every investor meeting and every sales conversation. I would also avoid simple automation tools (connecting apps via triggers and actions) unless you can build a connector library that is genuinely hard to replicate.
Q: How should I handle a prospect who says "we might just build this"?
Do not argue against it. Ask them to walk you through their build plan. Understand what they will build and what they will give up. Then ask: "What happens in six months when the engineer who built it moves to another project? Who maintains it? Who is on call when it breaks at 2 AM? Who adds the next feature?" Most build plans have no answer to these questions. The operations and maintenance story is where SaaS vendors win the build vs buy argument.
Q: Are there SaaS companies benefiting from the AI coding agent wave?
Yes, significantly. Companies that sell developer tools, API infrastructure, or the foundational layers that custom-built apps need are seeing tailwinds. Vercel, Supabase, PlanetScale, Clerk for authentication, Stripe for payments, Resend for email — these are the infrastructure picks-and-shovels plays for the custom-build wave. Every AI-built custom app still needs hosting, a database, authentication, payments, and email. The platforms that power those layers are seeing accelerated adoption.
Q: Should SaaS companies lower prices to compete with the build alternative?
Not as the primary strategy. Racing to zero on a fixed-cost base is terminal. The better response is to clearly demonstrate the value that justifies the current price, eliminate features or tiers that do not justify their price points, and improve the operational and maintenance story (reliability, security, support) that is the genuine advantage over custom builds. Selective pricing adjustments for at-risk segments can be tactical, but they should not be your defensive strategy.
Q: How real is the "good enough" problem for AI-built tools?
More real than the builders admit and less real than the SaaS vendors claim. The good enough problem is genuine for scale, security, and edge cases. An AI-built tool that works perfectly for 50 users often has real problems at 500. But the gap between AI-built and SaaS-quality is closing faster than most SaaS vendors acknowledge. The risk is that vendors use "good enough won't scale" as a comforting narrative that keeps them from confronting the structural threat. The truth is that good enough is good enough for many use cases, and the use cases where it falls short are narrower than they used to be.
Q: What is the single most important thing a SaaS founder can do in response to this shift?
Build genuine switching costs from day one. This means: become the system of record for data that matters, invest in integration depth that creates stickiness, design for data accumulation that makes your product smarter the longer a customer uses it, and tie your product to compliance or regulatory requirements in your customer's industry. A product with deep switching costs does not lose to an AI-built alternative — not because the alternative is impossible to build, but because the cost of switching is higher than the savings from building.
The build vs buy shift is not a binary. It is a gradient — and different SaaS products sit at different positions on that gradient depending on their defensibility, their category, and the sophistication of the customers they serve.
The vendors who will be hurt most are those who built businesses on the assumption that their product's feature set was their competitive advantage. Features are no longer a moat. AI coding agents can replicate features. What cannot be replicated is the data accumulated over years of production use, the compliance certifications that took two years to earn, the network of customers whose shared data powers the product's intelligence, and the operational reliability of a team that has been running this service at scale for a decade.
The SaaS companies that survive and thrive through this shift will be the ones that honestly audit their actual moats — not the features they list on the pricing page, but the structural advantages that would survive a capable engineering team spending six months building an alternative. If the honest answer to "what do we have that cannot be built?" is "not much," that is the most important strategic signal available.
The build vs buy conversation is going to happen in more procurement meetings in the next 24 months than in the past decade combined. How well-prepared you are to win that conversation — with data on switching costs, outcome metrics, and genuine structural advantages — will determine whether your SaaS business grows or shrinks in the era of AI coding agents.
The tools that collapsed the cost to build have not yet collapsed the cost to operate, maintain, and trust custom software at scale. That gap — between building and operating — is where the SaaS value proposition lives in 2026. Defend it aggressively.
Liked this? Read AI Agents Are Replacing Your SaaS Stack for the agent-driven disruption angle, and Vertical SaaS Opportunities for where the safer bets are.
AI agents are collapsing entire SaaS categories. Learn which tools are most vulnerable, how to build agent-native products, and how to adapt your existing SaaS before agents eat your lunch.
Curated guide to the best open-source AI agent projects in 2026 — browser automation, coding agents, research agents, and infrastructure tools with production readiness ratings.
Learn how vibe coding with AI tools like Claude Code, Cursor, and v0 lets solo founders build and ship products 10x faster — the complete playbook for AI-augmented development.