Linear #175: The Three AI Wedges That Are Working, The Story of Dockwa, One-Size-Fits-All Payment Models Are No Bueno
One vSaaS breakdown. One biz story. One 'how to'. In your inbox once a week.
If you missed our recent workshop it was INSANE. The most AI pilled GTM leader I know showed us exactly how to build/instrument Claude for his sales team.
His sales people don’t even log in to the CRM anymore…
If you want to watch the recording head here.
Alright, let’s get to it…
Why One-Size-Fits-All Payments Models Break as You Scale
Here’s something I think a lot of SaaS founders underestimate:
The biggest payments mistake usually isn’t choosing the wrong provider.
It’s choosing one based entirely on what you need today.
Because the reality is, no vertical SaaS company stays simple for long.
Early on, most teams optimize for speed. They want the fastest path to launch, the easiest integration, the fewest moving parts. Totally reasonable. When you’re trying to get product to market, nobody wants payments becoming a six-month side quest.
So, founders pick the provider that feels simplest.
Fast onboarding.
Plug-and-play setup.
Standard workflows.
Clean API docs.
All good things.
Until the business starts getting more sophisticated.
Because what a lot of founders realize too late is that most “simple” payments providers only
feel simple because they force everyone into the same box.
Same onboarding flow.
Same underwriting rules.
Same operational process.
Same merchant experience.
And that works… until it doesn’t.
Because if your company is growing, your payments needs are going to evolve fast.
Your first enterprise customer wants a custom workflow. A strategic prospect needs underwriting flexibility. Product wants tighter control over UX. Finance starts realizing payments isn’t just a side revenue stream anymore.
And that last part matters.
In a lot of strong vertical SaaS businesses, payments can become 30–40% of total revenue. Once that happens, it stops being “just infrastructure” and starts becoming a major part of the company’s economics.
That’s when rigidity becomes a real problem.
Because suddenly your team starts hearing: “
We can’t support that.”
“That’s outside our standard process.”
“That feature isn’t on the roadmap.”
And before long, you’re no longer building around what’s best for your customers.
You’re building around what your payments provider will allow. That’s a dangerous place to be. A lot of founders don’t realize how limiting that can become until they’re deep enough into scaling that switching providers feels painful, expensive, and operationally miserable.
By then, you’re stuck trying to grow on infrastructure that was built for an earlier version of your company.
That’s why smart founders don’t just ask, “Can this provider get us live?”
They ask bigger questions:
Can this partner adapt as we grow?
Can they support complexity as our business matures?
Does their roadmap actually move?
Will they still make sense when our needs look completely different three years from now? Because the best payments partners understand that scaling SaaS businesses don’t stay static.
What works at 100 merchants usually breaks at 1,000. What works for SMBs often doesn’t work for enterprise. What feels like an “edge case” today becomes normal once you scale enough.
It’s one of the reasons I’ve found Xplor Pay interesting. They’re one of the few providers I’ve seen that seem to understand this dynamic because they’ve actually operated vertical SaaS businesses themselves. They know firsthand how quickly payments needs evolve once a software company starts growing.
And that operator perspective matters.
Because payments isn’t just something you bolt onto your platform.
It becomes part of how your business scales.
And the best founders know this:
You’re not just choosing a payments provider for where your company is today.
You’re choosing one for where you want it to be three years from now.
Dockwa: Vertical Software for Marinas
Dockwa started from a very real, very vertical pain point: Mike Melillo and friends wanted to take a boating trip and couldn’t even get a marina to respond so they could give them money. That’s a great startup smell.
Broken communication, fragmented supply, obvious willingness to pay, and an industry still running on pen-and-paper workflows. Melillo then spent time on the docks in Newport, talked to marina operators, and realized the core problem wasn’t just reservations.
It was the lack of communication and the total absence of modern operating software connecting marinas and boaters. Dockwa was founded in 2014 and launched in May 2015, initially framed as the “OpenTable for boating.”
That’s a good founding story because it starts with a consumer pain point but immediately points toward a much larger operator workflow…
Early customers
The early wedge was geographically tight and operationally smart. Dockwa launched into New England in 2015 with a handful of marinas, then expanded across the East Coast before moving into the Midwest, Caribbean, Great Lakes, and beyond.
By mid-2016, the company said it had grown to more than 400 marinas across 22 states and four countries, and had facilitated more than 12,000 reservations in its first twelve months.
By late 2016, Melillo said the platform served more than 20,000 users and 450 participating marinas. What matters here is not just the raw count. It’s that Dockwa appears to have found early density in a place where operators talk to each other, seasonal demand is concentrated, and success stories travel fast.
One example they highlighted from that period was Edgartown, where the harbormaster reportedly doubled guests served after adopting the software. That’s exactly the kind of early-customer proof that helps a vertical SaaS company compound trust.
Product suite
This is where the company gets more interesting.
Dockwa did not stay a reservation tool.
Marinas are complex. They can be a grocery store, a gas station, a restaurant, a traffic coordinator, are parking lot operator, etc. A lot of tooling has to get built to be successful here.
On the boater side, the product is free and centered around discovery, booking, messaging, storage, payments, and wallet functionality.
On the marina side, the suite has expanded into reservations management, digital contracts, billing, POS, fuel dock workflows, slip assignments and maps, CRM, reporting, storage, and service management.
It also acquired Marinas.com in 2017, which added a large marine directory and a demand/discovery layer on top of the core workflow software.
That expansion path is textbook vertical SaaS.
Start with the narrow interaction that naturally sits between buyer and supplier. Then move into the operating layer underneath it. Then keep expanding until you increasingly look like the system of record.
Business Model
Dockwa’s GTM is what I’d call a two-sided vertical SaaS + marketplace hybrid.
The boater side is free, which helps reduce friction and build demand density. The marina side gets software, bookings, payments, communication tools, and operational leverage. That is a really nice motion because the marketplace does not just generate leads. It also creates workflow gravity. If boaters are already discovering, booking, and paying through Dockwa, marinas have a strong reason to adopt the software layer more deeply.
Early on, Dockwa also monetized the marina side through software subscriptions. In 2016 it launched Dockwa Connect at $299 per month for marinas. That tells you a lot. This wasn’t just a transactional marketplace hoping to live on take-rate. It was already moving toward recurring B2B software revenue. The Marinas.com acquisition reinforces that too. It suggests the company understood that discovery traffic, demand aggregation, and operator software all reinforce each other.
So the GTM flywheel looks something like this: free consumer adoption drives boater demand, marina adoption improves inventory and workflow coverage, better software deepens retention, and the marketplace layer keeps bringing in traffic and bookings.
Funding
In 2015, Dockwa announced $1.1M in additional seed funding, bringing total capital raised at that point to $1.4M. In 2016, it announced an additional $2M seed round. Newport Daily News later described the company as having raised $3.5M in venture capital by late 2016, which lines up directionally with those early reported rounds. Investors mentioned in the early coverage include David Skok of Matrix Partners, Brian Halligan, Mike Volpe, and Elias Torres, among others.
That matters because it implies Dockwa built a pretty substantial footprint without needing a massive venture balance sheet. In other words, this is not a burn-the-earth, hyperfunded vertical. It looks much more like a capital-efficient category builder.
Potential AI opportunities
Dockwa already sits on top of a lot of operational data: bookings, occupancy, boater preferences, contracts, payments, communications, timing, and service requests. That creates several obvious AI wedges.
The first is an AI dockmaster or marina operations copilot that handles inbound boater communication, answers availability questions, suggests optimal slip assignments, manages waitlists, and triages service requests. That alone could remove a lot of seasonal labor.
The second is revenue management. Dockwa already talks about helping marinas improve occupancy, and dynamic pricing is an obvious fit here. AI could push that much further by forecasting demand based on local events, weather, historical occupancy, vessel type, seasonality, and competitive supply.
The third is workflow automation across contracts, billing, collections, and service coordination. Marinas are exactly the kind of business where there’s a lot of repetitive admin wrapped around a physical asset. That is fertile ground for AI-native software.
And the biggest opportunity may be turning Dockwa from a booking-and-management layer into a real marina operator system that helps answer questions like: which slips are underpriced, which service requests drive the most margin, which transient guests should be converted into seasonal relationships, and where labor is being wasted.
Outlook for the future
I think Dockwa has the shape of a very good vertical software company because it followed a pattern I trust.
It started with a narrow wedge that was painfully obvious. It inserted itself into the transaction. It expanded into operator workflows. It built a two-sided network around the category. And it kept moving closer to the system of record.
That’s usually a good place to be.
It’s not a giant horizontal market. But it does look like the kind of category where one company can become the default infrastructure layer.
And if they successfully layer AI on top of bookings, pricing, communication, and operations, Dockwa could get a lot closer to being the operating brain for marinas rather than just the front door for reservations.
That is the real opportunity.
The Three AI Wedges That Are Working
The below was buried in a recent newsletter but I’ve been asked so much about it that I wanted to highlight it specifically…
The first is AI services.
This is maybe the most practical wedge because it goes straight at labor. In a lot of vertical industries, the software exists, but humans are still doing all the real work around it. They are checking, correcting, reconciling, interpreting, and pushing the workflow forward manually. So instead of starting with a better interface, AI services starts with a better way to do the work itself.
Camber is a great example of this. Healthcare reimbursement has historically required huge amounts of specialized human effort layered on top of bad systems and fragmented processes. Claims have to be submitted, fixed, chased, and reworked. Entire services businesses grew up around that pain. What Camber does is turn that labor-heavy reimbursement problem into a software problem. That is why the wedge is so strong. They are not just selling a nicer billing tool. They are going after work that used to require armies of people.
And that is a useful lens for rethinking something like the Toast map. In restaurants, a surprising amount of operational drag still looks like services work hiding inside the business. Catering intake. Guest recovery. AP reconciliation. payroll exception handling. Supplier coordination. These are all places where people are still acting like an internal services layer because the software never really absorbed the work.
The second wedge — and I think the most exciting — is the industry-specific GPT.
This is where things start to get really interesting.
Because now you are no longer just automating a step in the workflow.
You are building an intelligence layer for the vertical itself.
That is a much bigger idea.
An industry-specific GPT is not just a chatbot with a little fine-tuning. It is not just generic AI wearing the clothes of a vertical. At its best, it starts to understand the actual language, logic, edge cases, constraints, and judgment patterns of the domain. It behaves less like a feature and more like an emerging operating intelligence for the industry.
OpenEvidence is a great example of this. The reason it is powerful is not that it is “ChatGPT for doctors.” That framing is too shallow. What makes it compelling is that it is becoming a medical intelligence layer grounded in the realities of clinical decision-making. It is useful because it understands the domain well enough to help practitioners reason inside it.
And once you start thinking this way, the workflow map changes dramatically.
Because now the question is not just: where can I automate labor?
The question becomes: where does this industry need a brain?
What would the restaurant equivalent of that look like?
It would not just answer questions about menu items or write a promo email.
It would understand the operating reality of restaurants. It would understand labor pressure, table turns, reservation pacing, kitchen bottlenecks, menu mix, guest recovery, promo strategy, inventory risk, staffing tradeoffs, refund behavior, and the way all of those things interact.
That is a completely different category of software.
At that point, you are not just building around the workflow. You are building a domain-native intelligence layer that can increasingly guide the workflow.
That is why I think this wedge is the most interesting one.
If the AI services wedge helps you do the work, the industry-specific GPT wedge helps you understand the work at a much deeper level than old software ever could.
And in the long run, that may be the more powerful position.
The third wedge is building agents on top of the system of record.
This one is a little more tactical, but it is incredibly important because it acknowledges a simple truth: in many verticals, the incumbent system still has the data gravity.
It may be hated. It may be clunky. But it is embedded. It is where the records live. It is where the workflow officially lands. That means one of the smartest ways to wedge in is not to replace it immediately, but to start from it.
Use the system of record as the foothold. Read from it. Write back to it. Make it smarter. Reduce the labor around it. Turn it from a passive database into something that feels more action-oriented. You essentially build Agents on top of it.
Datagrid is a great example of this pattern. It does not begin by asking the construction company to replace the system of record (IE Procore). It starts from the fact that the CMS is already embedded in the workflow and already the source of truth. The wedge is to capture the conversation, structure the documentation, and make the surrounding workflow dramatically more usable while integrating into the existing record system. That is a very different strategy from trying to rip out the incumbent on day one.
There is a very obvious parallel in restaurant software too. If you were attacking the Toast map this way, you might not begin by replacing Toast or the broader stack. You might start by asking what AI can do when it sits on top of the systems that already exist. Can it absorb the labor around them? Can it turn raw operational data into clear actions? Can it surface exceptions instead of forcing operators to dig? Can it make the existing stack feel much more intelligent without forcing a painful rip-and-replace?
That is wedge number three.
And the important thing is that these wedges are not mutually exclusive. In fact, the best companies will probably move through them over time.
They may start with AI services, because that is where the urgency and labor budget live.
Then they may deepen into an industry-specific GPT, because that is where the real intelligence advantage gets built.
Then they may sit on top of — or increasingly absorb — the system of record, because that is where the workflow gravity and defensibility live.
That progression feels right to me.
Do me a solid and forward to a friend :-)