The Asset Underneath Vertical Software

The Asset Underneath Vertical Software

Chris Andrews & Chris Collins, PSG Vertical Technology

The AI differentiation slides that get our attention don't describe the software. They describe an asset underneath it.

That distinction has become the whole game for us. We still back great vertical software built for an underserved industry, and that conviction hasn't changed. But the bar has moved. Think about what used to make those businesses defensible on their own: a learned interface, workflow logic that took years to encode, data access that required real integration work. All of it turned out to be expensive to build rather than fundamentally hard to replicate, now that a capable AI team can approximate a good deal of it quickly. Good software for a hard industry is still necessary, but it's no longer what decides whether we lean in. That now comes down to whether there's something underneath the product that a competitor can't shortcut with good engineering.

One framing note: we lead the Vertical Technology team at PSG, not Vertical Software. That's deliberate, and it reflects where the portfolio has already gone. A growing share of companies we back are AI-native from the ground up, with the intelligence layer as the product rather than a feature added to an existing SaaS business. Everything below applies across both. And if you're building one of these companies, what follows is the lens we'd bring to a first conversation with you. We'd rather you see it up front than reverse-engineer it from our questions.

What gets us leaning in

The question isn't whether a company uses AI well; nearly every pitch says yes to that now. It's whether the business becomes more valuable as AI capability improves or gets commoditized by it, and who captures the difference. Four questions do most of the work for us, roughly in order of how durable they've proven.

1. Does the platform generate its own data through real transactions, at a specificity no general model was trained on, and does that data compound the longer it runs? Not "we have data." Data the business itself produces as a byproduct of doing the work, and that gets more valuable with use rather than less.
2. Is there a two-sided network where each side is measurably better off because the other showed up? Not user count. Real dependency, specific enough that each side would notice, concretely, if the other left.
3. Does money, a contract, or fulfillment actually run through the platform rather than alongside it? This makes a business durable because displacing it is operationally tedious and relationship-dependent, not because it's technically hard to copy.
4. Does the workflow resolve into something physical or regulated, where AI augments the platform rather than substituting for it? Software that orchestrates a real-world outcome sits in a different position than software that only moves information around.

The first and third look similar but aren't, and the gap between them is often where a business turns out to be thinner than it looks. A platform can move an enormous amount of volume and retain nothing from it that makes the product better. It can also accumulate genuinely rich data while sitting outside the transaction, reading another system and depending on that system to keep the connection open. Holding both at once is a different business than holding either one.

What we're most confident in isn't any single question but the combination. A well-capitalized competitor entering a business that clears all four must replicate an installed base, a working network, a transaction relationship, and a footprint in the physical world simultaneously, not just ship a better interface.

Keeping ourselves honest

"Proprietary data" and "network effects" are the two most-used phrases in vertical software right now, and that includes how we talk if we're not careful. So we try to get specific early, mostly about our own language. Is the data differentiated in the way a model actually needs, or just plentiful? Would each side of the network notice the other's absence, or is that a user count wearing a network-effects label? Does the transaction run through the platform, or beside it? We put these on the table in a first meeting rather than saving them, because they're the questions that decide the answer, and a founder deserves to know what we're solving for while there's still time to argue with us about it.

Where it clicked for us: Dockwa

We recently invested in Dockwa, which is building the operating system for the marine economy: roughly $57 billion in annual boater spend across slips, fuel, service, and storage, and one of the last great consumer categories to fully digitize.

Start with the network, because it explains most of the rest. Dockwa reaches over 90% of the top 100 U.S. harbors and now has over 500,000 boaters in its network, with nearly 200,000 transacting annually. On the other side, its software runs reservations, payments, and daily operations at nearly 4,000 marinas. We believe neither side has an easy substitute for the other. We're not aware of another channel that puts a marina in front of that many boaters actively booking transient nights. It is unlikely that a boater planning a multi-stop cruise can find comparable coverage of the harbors along the way. That mutual dependency, not the customer count, is what the second question is really asking about.

That network has another unusual feature. In most consumer categories, discovery, booking, and the software that runs the operator's business sit across different solutions. Marinas were small and seasonal enough that the category never split that way. Dockwa can see the search on Marinas.com, the booking and payment, what happens at the fuel dock and ship store, and where the boat goes next. The intelligence is more useful because the loop was never broken: demand, inventory, transaction, and on-site activity live in the same system rather than being reconstructed from disconnected signals.

We did a management presentation this past February at a marina in Palm Beach, a welcome break from running diligence out of Boston in the middle of winter. What we saw on the docks made the case better than any slide could have. A dockhand walked the marina with a tablet, checking in an arriving boat in real time. Twenty minutes later that boater's tab picked up sunscreen and ice at the ship store, on the same account, reconciled automatically. At the fuel dock, a swipe closed out without anyone touching a spreadsheet.

It would be fair to look at that and see mobile software with a point-of-sale integration, which is close to the category we just described as expensive rather than defensible. The difference is what happens when the software is wrong. An informational product that makes a mistake produces a bad answer. Here, a mistake means a boat sent to an occupied slip, a fuel sale that doesn't reconcile at close-out, or a guest turned away from a harbor at dusk with nowhere else to go. Being reliable in that environment is earned over years of running real transactions in real conditions, and it isn't something a strong team can infer from the outside, however good the model. It's also where the third and fourth questions meet: the money is moving through the platform rather than beside it, and the workflow ends in something physical. The software's job is to make the person on the dock faster and the business more accurate, not to replace the dock.

That physical constraint matters more as models improve. As AI makes software cheaper to build, the scarce asset underneath the software does not get cheaper with it. A slip is fixed and perishable, and there are only so many available in Newport in July. If parts of the software layer commoditize, control of the interface to scarce, real-world supply can become more valuable, not less. Dockwa sits at that interface on both sides of the market.

Underneath that experience is Marine Graph: 11 years of transaction history across over 900,000 unique boats and 76 million nights booked, generated continuously by Dockwa's own platform rather than licensed or assembled from public sources. That asset is what makes Telescope, Dockwa's dynamic pricing and revenue-intelligence engine, work, and the mechanism is worth being precise about. Telescope isn't a generic pricing model dropped onto a marina's spreadsheet. It works because Dockwa owns both sides of the transaction in one system: real boater booking behavior and price sensitivity on the demand side, live slip inventory across over 90% of the top 100 U.S. harbors on the supply side. Seeing both at once is what lets it compare real demand against real available inventory. The alternative is estimating one side from a proxy, which is the best any horizontal AI tool bolted onto a marina's disconnected legacy systems could do. The scale in transient bookings and the richness of the data aren't two separate advantages. The scale is what makes the data predictive in the first place, and it compounds: every booking, every season, every close-out adds to the thing that makes the next forecast better. That's the first question answered about as cleanly as we've seen it: not data the company acquired, but data the business produces by operating.

The boat record is a useful example of why that data is hard to recreate. Dockwa's platform has records tied to over 900,000 unique boats, built through years of actual activity across its network. That record is created transaction by transaction; it cannot simply be assembled from the outside. This gives Dockwa valuable insights into where and how boats move from harbor to harbor.

AI agents may make that transaction position more important. If a boater asks an agent to find and book a slip instead of opening an app, the agent still needs live inventory and an endpoint that can complete the booking. Discovery interfaces can become easier to replicate while the value of the underlying supply and transaction connection increases. In that world, the durable position is not necessarily the interface the consumer sees; it is the platform the agent has to call to get the job done.

If you're building in a category like this

None of this is a checklist, and the businesses we've backed haven't cleared every question perfectly. It's the lens we're using now, and we hold it with some humility, because the technology underneath it keeps moving. If you're building the operating system for an under-digitized industry, we'd like to meet you and learn more about your business.