April 16, 2026
If your app is a glorified CRUD layer over a database, someone can vibe-code a replacement. Defensibility now comes from how deeply your software touches the real world: money, customers, sensors, robots.
A few years ago, shipping a polished SaaS UI with a clean API and a couple of integrations was enough to hold a market for a while. That era is over. The bar to build software has collapsed. A single developer with AI tools can stand up a working CRUD app in a weekend. Investors are already pricing this in. Public software multiples compressed through 2025 as buyers started asking the obvious question: if an agent can rebuild this, what am I paying for?
Software itself is no longer the moat. So what is?
This is Part 2 of the SaaS defensibility series. Part 1 argued that profitability is the new baseline in a market where capital is expensive and growth-at-all-costs is dead. This post is about the second layer: making your product structurally difficult to rip out. The argument is simple. The more your software touches the physical world, the harder it is for a buyer to replace it with something a competitor vibe-coded last month.
Getting physical does not mean building hardware. It means your software does something in the real world that has a consequence. It moves money. It dials a customer's phone. It reads a sensor on a warehouse floor. It tells a robot to pick an item off a shelf. It prints a shipping label that triggers a truck.
Each of these is a different kind of physical. What they share is that the software is not just rearranging rows in a database. It is interfacing with something that exists off the screen, and that interface has weight. When the interface breaks, real things break. When a buyer considers replacing the software, they are not just replacing code. They are taking on the risk that money stops moving, that customers stop getting called, that shipments stop going out the door.
That risk is the moat.
Think about the difference between two products a mid-size B2B company might buy.
Product A is a project management tool. It has tasks, statuses, comments, assignees, and a nice Kanban view. Everything it does lives inside its own database. If a competitor shows up with a cleaner UI or an AI feature the incumbent lacks, the switching cost is low. Export the data, import it somewhere else, retrain the team over a Tuesday. A month later nobody remembers the old tool.
Product B is an accounts-payable platform. It pulls invoices, approves them, and then actually moves money out of the customer's bank account to pay vendors. It connects to ACH rails. It has vendor-specific payment routing. It holds audit history the CFO will need during tax season. Switching this out is a project with a capital P. Legal has to review the new vendor. Finance has to re-onboard every supplier. There is a migration window where payments could fail and vendors could walk. The CFO is not going to approve this unless there is a crisis.
Both products are "software." One is a CRUD layer on a database. The other is software that moves money. The economics of replacing them are not comparable, and neither are their margins or their retention curves.
This is why venture capital has quietly rotated back toward business models it used to avoid: hardware-enabled software, marketplaces, vertically integrated services. These categories were out of favor because they looked messy next to clean SaaS gross margins. Now they are in favor because AI cannot easily replicate physical infrastructure, network effects, or the operational overhead of actually integrating with the world.
Not every product needs to move money or deploy robots. There is a spectrum, and every rung up it raises the switching cost.
Fintech and payment rails. The highest-value tier. If your software moves funds, touches bank accounts, integrates with card networks, or handles regulated financial flows, it is structurally hard to replace. The compliance burden alone keeps would-be competitors out. The AI industry's own pricing analysts have noted that fintech and vertical AI solutions are already commanding premium economics precisely because the cost of a wrong answer is money moving to the wrong place. That consequence disciplines both the vendor and the buyer.
Customer-facing automation. Any software that contacts your customer's customers raises the stakes. Outbound SMS. Email that goes to real inboxes. Automated voice calls to leads. Appointment scheduling that books onto actual calendars. If this software misfires, the buyer's customers see it, and the buyer's brand takes the hit. That risk makes the buyer much more careful about ripping it out. The switching project is not just a data migration. It is a trust migration with their own customers in the loop.
IoT, logistics, and hardware integrations. The deep end. Warehouse management systems reading barcode scanners and telling forklifts where to go. Fleet software pulling telematics from trucks and dispatching drivers. Manufacturing software talking to PLCs on a factory floor. Medical device software integrated with hospital infrastructure. When your software is downstream of physical sensors and upstream of physical actions, switching it out is a capital project, not a software decision. These categories also tend to involve proprietary data assets that accumulate defensibility over time, which makes them compound rather than erode.
Each tier raises the buyer's perceived risk of replacement, and perceived risk is the currency of defensibility.
The worry that an AI-powered competitor will vibe-code your product in a weekend is real for pure UI plays. It is much less real for products that live in the physical world. Here is why.
A competitor can generate your schema and rebuild your screens. What they cannot generate is your bank partnerships, your PCI compliance posture, your years of integration work with a specific ERP that your 200 customers are already running, your driver roster, your carrier contracts, or the dozens of edge cases your software has already learned about a specific sensor on a specific factory line. Each of those is a chunk of physical-world friction that lives outside the codebase. You cannot vibe-code a bank partnership. You can only earn one.
This is the same pattern analysts now call out in SaaS defensibility scoring: data moats, regulatory compliance, integrations that are "mission-critical" rather than "useful," and categories where the software functions as a system of record rather than a workflow wrapper. Systems of record are sticky because they are where the truth lives. Physical integrations are sticky because they are where the action lives. Both beat clean UI in a market where UI is cheap.
If you are early, pick your problem space with this lens in mind. The most defensible new companies are not going to be horizontal productivity tools. They are going to be vertical products that own a physical workflow in a specific industry. Plumbing company tech. Dental practice ops. Trucking compliance. Specialty clinic billing. Pick a vertical, get close enough to the operators to understand what their software actually has to do in the world, and build that.
If you already have a CRUD-layer product, look for the upgrade path. Where does your data end up going? Is there a version of your product where instead of handing a report to a human, you take the action? Instead of showing the invoice, you pay it. Instead of listing the lead, you call them. Instead of flagging the inventory, you reorder it. Each step from observation to action is a step into the physical world. Each one raises your switching cost. Each one justifies a pricing model tied to outcomes rather than seats, which is the other half of the defensibility story.
The through-line is the same in both cases. Stop competing on UI. Compete on what your software is allowed to do in the real world, and on how much trust you have earned to do it.
Describe your software or AI project. Get a full scope with story-point pricing, sprint estimates, and a downloadable plan in minutes. No calls, no waiting.
Free and instant. Try the calculator now.
Does "getting physical" mean I have to build hardware?
No. It means your software has to do something in the physical world, which can be as simple as moving money, sending a text to a real phone, or reading a sensor. Hardware is one path to defensibility, but it is not the only one. A pure-software product that is deeply integrated into payment rails, customer communication, or logistics infrastructure is already "physical" in the sense that matters for switching cost.
What if my product is a pure horizontal SaaS tool that cannot easily touch the physical world?
Then you are in a harder category and you need to compensate on a different axis: proprietary data that compounds over time, a system-of-record position that other tools depend on, or a deep vertical specialization that makes you the default in a narrow segment. If none of those apply, the honest answer is that profitability and efficiency have to carry you, because moat is not going to. Price accordingly and run lean.
Is this just an argument for vertical SaaS?
Vertical SaaS often ends up in this category because verticals force you to engage with the physical workflows of a specific industry. But the principle is broader. A horizontal payments platform is physical. A horizontal IoT platform is physical. The question is not vertical versus horizontal. The question is whether your software has real-world consequences when it runs.
Doesn't regulatory overhead slow you down and hurt margins?
Short term, yes. Long term, it is the feature, not the bug. The same regulatory overhead that makes it expensive for you to operate is what makes it prohibitive for a competitor to replicate. Companies that pick the "easy" categories end up with the easy competition. If building your product requires months of compliance work and bank onboarding, a vibe-coded weekend project is not going to show up in your market and win.
How should I evaluate my current product's defensibility?
Ask what happens when a customer tries to leave. If the answer is "export the CSV," you are exposed. If the answer is "re-onboard 400 vendors, re-certify with our bank, and run parallel systems for 90 days to make sure payroll doesn't break," you are defensible. Most real products land somewhere in between. The job is to keep moving toward the second answer.
Does physical defensibility matter if my buyer is not sophisticated?
It matters more, not less. Unsophisticated buyers are the ones most likely to be pitched on a cheaper AI-generated alternative and to take the bait if the switching cost feels low. When the switching cost is genuinely high, even an unsophisticated buyer will not attempt it. The moat does the work you cannot rely on the buyer to do for themselves.
Andreessen Horowitz. "The Race to Capture Value: Cloud Lessons for the AI Era." a16z. https://a16z.com/cloud-lessons-for-the-ai-era/
Bessemer Venture Partners. "The AI Pricing and Monetization Playbook." BVP Atlas. https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook
Boston Consulting Group. "Rethinking B2B Software Pricing in the Era of AI." BCG Publications. https://www.bcg.com/publications/2025/rethinking-b2b-software-pricing-in-the-era-of-ai
The SaaS CFO. "The SaaSpocalypse: AI Agents, Vibe Coding, and the Changing Economics of SaaS." https://www.thesaascfo.com/the-saaspocalypse-ai-agents-vibe-coding-and-the-changing-economics-of-saas/
Oliver Wyman. "How AI Is Reshaping SaaS Valuations: A Guide for Investors." https://www.oliverwyman.com/our-expertise/insights/2026/apr/how-agentic-ai-reshaping-saas-valuations.html
Ghanta, Praveen. LinkedIn post on hardware-enabled software and defensibility. https://www.linkedin.com/in/pghanta/
Related: How Much Does It Cost to Build an App? · Software Cost Estimation for Non-Technical Buyers
