2025-10-15 00:49:21
Product market fit is the startup holy grail. “Product” and “market” are essential, but a startup’s data model is the dark matter that holds them together.
“Data model” refers to what a startup emphasizes in its product, i.e., which parts of reality matter most in how the product represents the world. It’s the core concepts or objects a startup prioritizes and builds around, the load-bearing assumptions at the heart of their strategy and worldview. It’s partially captured in the database architecture (hence the name), but it shapes everything from the UI/UX to the product marketing, pricing model, and GTM strategy.
This shows up differently depending on the layer. In the database, it’s which tables are central and how they relate. In the product, it’s which UI elements dominate and what actions are easiest. In pricing, it’s what you charge by. In GTM, it’s the workflow or pain point you lead with. But they all stem from the same choice about what deserves to be the center of gravity.
Every founder has a data model, whether they realize it or not. Either you choose it explicitly or it gets inherited from whatever you’re copying. Most founders never articulate it. By the time the architecture solidifies around these implicit choices, it’s nearly impossible to change.
And that’s generally fine, because most companies shouldn’t innovate on their data model. Customers have existing mental models and workflows built around incumbent tools. Fighting that is expensive and slow. But at the extreme ends of markets—where you’re toppling multi-billion-dollar incumbents or creating entirely new categories—a distinctive data model becomes a critical and non-obvious edge.
The biggest breakout companies of the last decade often trace their success to an early, non-obvious data model choice that seemed minor at the time but proved decisive. Consider:
Slack’s persistent channels vs 1:1/group messages: While Yammer and HipChat replicated email’s ephemeral group messages, Slack made persistent, searchable channels the atomic unit. This created organizational memory—every decision, discussion, and document lives forever in context. Incumbents couldn’t match this without rebuilding from scratch.
Toast’s menu-item-centric architecture vs generic POS SKUs: Toast makes menu items first-class objects with embedded restaurant logic—prep times, kitchen routing, and modifier hierarchies built in. Generic point-of-sale systems treat menu items as retail SKUs, requiring third-party integrations for kitchen workflows. Toast’s model enables native order routing and real-time kitchen management, plus natural extensions like ingredient-level inventory and prep-based labor scheduling—creating a locked-in ecosystem that becomes the restaurant’s operational backbone.
Notion’s blocks vs Google’s documents: Google Docs gives you documents; Notion gives you Lego blocks. Every piece of content can be rearranged, nested, or transformed into databases, kanban boards, or wikis. This modularity collapses entire tool categories into one system. Traditional tools can’t compete without abandoning their document-centric architecture.
Figma’s canvas vs files: Photoshop and Sketch are built on local files. Figma is built on a shared web canvas where everyone sees changes instantly. This eliminates version conflicts and “final_final_v2” chaos. Adobe couldn’t respond without deprecating their entire desktop-first ecosystem.
Rippling’s employee data model vs siloed tools: Rippling treats the employee record as the lynchpin connecting HR, IT, payroll, and finance. Not separate products sharing data, but one product with multiple views. Each new product module is automatically more powerful than standalone alternatives because it inherits full employee context. Competitors remain trapped in single categories or attempt inferior integrations.
Klaviyo’s order-centric data model vs email-centric tools: MailChimp optimizes for email campaigns. Klaviyo optimizes for customer lifetime value by making order data a first-class citizen alongside emails. This lets e-commerce brands segment by purchase behavior, not just email engagement. Generic email tools can’t match this without rebuilding for vertical-specific data.
ServiceNow’s connected services vs standalone tickets: Traditional help desks treat tickets like isolated emails. ServiceNow links every ticket to a service map—showing which system is down, who owns it, and what it affects downstream. This transforms IT from ticket-closing to problem-preventing, making ServiceNow irreplaceable once companies reorganize operations around this model.
The importance of a differentiated data model is rising dramatically. AI is commoditizing code. Technical execution is table stakes rather than a competitive advantage. AI can generate code, but it can’t refactor the organizational reality customers have built around your architecture—the workflows, integrations, and institutional muscle memory that compound over time.
Meanwhile, many markets have become so crowded that single-product companies can’t survive. This is particularly true in vertical markets, where companies are expanding into adjacent software products, embedding payments and other financial products, and even competing with their customers’ labor and supply chains with AI and managed marketplaces.
This all points to the same conclusion: when code is cheap, competition is fierce, and vertical depth matters, your data model is the foundation of your moat. The companies that win won’t be those with the most or even the best features. AI will democratize those. The winners will be built on a data model that captures something true about their market, which in turn creates compounding advantages competitors can’t replicate.
Consider how this plays out. Rippling’s employee-centric model made it trivial to add payments, benefits, and spend management. Each new product inherits rich context, making it instantly more powerful than standalone alternatives. Toast’s menu-item architecture naturally extended to inventory, labor, and supplier management. The data model wasn’t just their first product decision. It was their platform destiny.
The path to a differentiated data model depends on your market. The more horizontal you go, the more your moat comes from technical and interface innovation. The more vertical you go, the more your moat comes from elevating the right domain objects with the right attributes.
Horizontal tools serve broad use cases where underlying concepts are already familiar. Leverage comes from changing how the product is built or experienced. Notion reimagined documents as composable blocks. Figma rebuilt the foundation entirely as a multiplayer web canvas.
Vertical tools serve specific industries with deep domain complexity. Leverage comes from what you choose to emphasize. Toast elevated menu items—not transactions—with prep times and kitchen routing as first-class data. Klaviyo promoted order data to equal status alongside email metrics.
A good place to start is by looking for model mismatches in existing successful products. Where are incumbent products forcing an incorrect or outdated model on their customers? Where are customers using workarounds—spreadsheets, low/no code tools, extensive in-product configuration—to make the product match how they think and work?
Despite all the emphasis on data models, start with the workflow, not the technical implementation. Don’t ask “what data do we need to store?” Ask “what’s the atomic unit of work in this domain?” For restaurants it’s the menu item. For design it’s the canvas. For employee operations it’s the human.
If you’ve already built a product, you can audit how powerful and correct your data model is. Open your database schema and see which table has the most foreign keys pointing to it. Is that the atomic unit your customers actually think in? List your product’s core actions. Do they all strengthen one central object, or are you building a feature buffet? What would break if you deleted your second-most important table? If the answer is “not much,” you probably have the wrong data model.
Test whether your data model creates compound advantages. When you add a new feature or product, does it automatically become more powerful because of data you’re already capturing? If your answer is “we’d need to build that feature from scratch with no inherited context,” you don’t have a compounding data model—you have a product suite. The right model creates natural expansion paths that feel obvious in retrospect but were invisible to competitors.
Your data model is your destiny. The paradox is that this choice happens when you know the least about your market, but that’s also why it’s so powerful when you get it right. Competitors who’ve already built on different foundations can’t simply copy your insight. They’d have to start over, and by then, you’ve compounded your advantage.
My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: [email protected]
2025-08-13 21:34:38
You might’ve heard the joke: airlines are just credit card companies that happen to own planes. It isn't far from the truth. Loyalty program fees generate the bulk of US airline profits.1
Airlines represent an increasingly common pattern: X is just a [bank/lender/issuer] that sells [unrelated, non-financial product].
Examples include auto and equipment manufacturers like Toyota and John Deere, which have extensive financing arms, homebuilders like D.R. Horton, which offer vertically integrated mortgage origination, and wireless carriers like AT&T, which earn hefty fees from device insurance and financing.
Modern software platforms have transformed this pattern into a powerful strategy that’s upending financial services and software alike. Restaurant owners no longer go to Wells Fargo for their card payments, they go to Toast. Landlords no longer wait in line at Chase to deposit checks or get loans, they use Yardi, etc.
These platforms—from the multi-billion-dollar pioneers like Toast, Shopify, and ServiceTitan to the crop of upcoming challengers—all represent the new strategy of embedded fintech, or when a non-financial company offers financial products that are highly contextual, curated, and customized for the company’s existing customers.
To appreciate the power of embedded fintech, consider the contrast between customers in line at the airport and those at the bank. Airline passengers may be very different from each other—different ages, different income levels, different reasons for traveling, different travel frequencies, and so on. But they all have one thing in common: a need to fly. Meeting that need is the airline’s main job, and they spend aggressively to fill seats on their planes. But airlines are notoriously low-margin businesses, and now that they have a captive audience, they see a cross-sales opportunity too good to miss. Airline credit card and loyalty schemes are designed to cross-sell relevant, complementary products to this captive audience.
Contrast the airport line with the line at your local bank. The people here are more diverse than at the airport, as are the services they’re waiting for. You may be next to a restaurateur setting up card payments, a construction company owner applying for a loan, new parents opening a 529 account, and a local lawyer opening a checking account. To appreciate the diversity, just look at the online product offering from Chase: everything from checking accounts to Disney Visa Cards and private banking to home mortgages and cross-border payments.
Both airlines and financial services are highly competitive industries. Both spend aggressively to acquire new customers, and both try to sell new customers as many products as possible to cover their acquisition costs and increase retention. The difference is that bank customers are so diverse that it’s impossible to customize an experience for them. Airline customers, by contrast, have just enough in common that it’s possible for airlines to customize experiences for them. That ability to customize is what gives embedded fintech its power.
Platforms with embedded financial services (PEFS) have been at the forefront of refining embedded fintech. PEFS like Shopify ($190B market cap), Toast ($25B), and ServiceTitan ($10B) are nominally software companies that serve well-defined customer segments or needs: Shopify is the one-stop shop for ecommerce merchants, Toast for restaurateurs, ServiceTitan for field service businesses, etc.2
But all earn 25% to 50%+ of revenue from financial services—everything from payments and lending, to payroll, spend management, and more. The revenue share is even higher for newer PEFS that are more deliberate about their financial product strategy. Let’s discuss some of the ways they’ve refined their product strategies.
PEFS target well-defined customer segments or needs, rather than serving a wide range of customers. They don’t try to be everything to everyone; they instead try to be everything to one type of customer. Contrast the generic, impersonal experience a lawyer, restaurateur, and plumber will get from a Chase branch with the highly customized, trusted experience they will get from a Clio, Toast, and ServiceTitan, respectively.
Targeting a specific audience enables PEFS to solve—and monetize—multiple problems for that one audience. Call this focus on being everything to one type of customer a maximalist product approach. The maximalist approach is best described by Parker Conrad's Compound Startup strategy, which leverages a single platform and shared infrastructure to launch a compelling bundle of products quickly to increase LTV and retention.
The maximalist approach and the compound strategy both extend to financial products, which PEFS treat as strategic priorities rather than afterthoughts. The compound strategy naturally complements many B2B workflows (see “B2B payments aren’t payments, they’re workflows”). Financial products have the added benefit of transactional business models rather than SaaS, which lowers the platform’s nominal usage cost for customers.
These financial products are deeply integrated from the start, so they create a unique flywheel that increases adoption and reduces risk. Beyond the benefits of zero CAC and high cross-sell rates, risk is an underappreciated benefit of embedded fintech. Most financial products require some risk assessment and underwriting. This is much easier when underwriting a specific type of user and business, and when you have a broader, longitudinal view of their activity via software.3
PEFS play a critical role in acquiring users and customizing both financial and non-financial products for their specific customers. But financial products come with onerous regulatory, compliance, risk, and capital requirements. Those requirements are why PEFS rely on a rising number of embedded fintech vendors (EFV) to embed and monetize financial products. Examples include Rainforest for payments and Unit for banking.
EFVs serve as a critical abstraction layer between software platforms and financial infrastructure providers like sponsor banks, card issuers, and lenders. Those providers don’t have the technical chops or embedded expertise to support fast-moving software platforms, and the individual platforms are unlikely to have the scale or expertise to work directly with a financial infra provider.4
EFVs meet the challenge of making financial infrastructure easy to embed, customize, and use across diverse platforms and use cases. Their success depends on mastering both the financial primitives they're built on and the unique requirements of each vertical market they serve. Most importantly, they need to deliver an exceptional experience both for the developers who integrate their solutions and for the end users who interact with them.
EFVs have made the wide array of financial products and services that banks offer embeddable within software platforms. Major categories like payments and lending have existed for a while, with companies like Stripe and Fundbox, but modern challengers like Rainforest, Unit, and Pipe have extended and accelerated adoption. Now nearly every product category has an embedded option:
Although EFV is a broad and fast-moving model, there are a few noticeable trends. EFVs are supporting a broader sliding scale of integration options, from fully built-out white-label components to raw APIs and platform ownership of critical functions like risk and underwriting.
Many PEFS are launching multiple embedded products and want the ability to pick and choose the best vendors for different functions like payments and lending. This development is leading EFVs to be more composable and interoperable—witness the integration of Rainforest with Unit. Many scaled EFVs are themselves going multi-product in an attempt to capture multiple financial use cases.
Finally, many EFVs are taking a cue from the platforms they serve and providing tools that complement their financial primitives. Think, for instance, of a card issuer providing embedded spend-management tools. Embedded tools like these offer higher margins and increase adoption.
Embedded fintech is so powerful because it changes the way consumers and businesses access financial services. It reflects the broader trend of offering more convenient, customized, and contextually relevant products and experiences enabled by software and the internet. Giants like Stripe and Toast have shown the power of embedded fintech. But we're only at the end of the beginning. New waves of natively embedded companies, particularly in vertical software, are building even larger and more ambitious companies with the model.
My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: [email protected]
This isn’t just a B2B strategy. For example, Uber offers a range of curated, customized, and complementary products to drivers, from a card with high cash back on gas and EV charging, car rentals and sales, and even bundled insurance.
This is a critical topic that we don’t have enough space to cover here, but if you’re interested in learning more, check out “The best companies turn risk into leverage” and “Price and shape risk that others can’t or won't".
For more on embedded payments in particular, check out “Payfac in 1,000 words”.
2025-05-13 21:35:07
Imagine you’re the world’s most entrepreneurial dentist, the Mark Zuckerberg of molars. You’re great at cleaning teeth, but you’re also great at running a practice. You have your own playbook for the dental business.
Thanks to your playbook, your practice is larger and more profitable than the market average. You’ve surveyed your dentist friends. You’ve learned that you’re the best at acquiring patients, running your back office, configuring your CRM to minimize cancellations, and getting paid quickly. But you aren’t satisfied with cleaning teeth all day. You want to build a dental empire. The gap between the average business and what’s possible with your playbook is your opportunity.
How do you start your empire? Until recently, there were two broad and distinct paths: private equity (PE) and venture capital (VC).
In the PE model, you’d raise money to acquire a controlling stake in one or more practices. Then you would have full control to implement your playbook and manage those practices day-to-day.
In the VC model for B2B software, you’d raise money to start a company that builds software that codifies your playbook for any practice to implement. Maybe it’s a suite of CRM, scheduling, and billing tools, with opinionated workflows and design choices specifically for dental practices. You wouldn’t own or manage any practices directly, but your software would help them run better.
Both models start with the same principles: (1) the average company in a given vertical isn’t run as effectively as it could be, and (2) you have the insights and playbooks to run the average company more effectively. You believe you can close the gap between the blue and green dots, and get paid handsomely for it:
However, the PE and VC models take very different approaches to point #2. The tradeoffs of each model are most obvious in their approaches to control, concentration, and value capture.
The PE model is high control, high concentration, and high value capture. It says, “This specific business can be run better, and so it’s likely undervalued. I’m going to buy and run it, applying my playbook. As the business grows and becomes more efficient, it will become more valuable. I’ll benefit from the increased equity value.”
The VC model (at least within B2B software) is low control, low concentration, low value capture relative to an individual business. It says “There are lots of businesses in this market, and most of them could be run better. I’m going to build software that helps them do that. I’ll charge a small fee, but will sell it to many businesses.”
The PE and VC models are extreme ends of a spectrum, rather than distinct models. PE and VC firms are both in the business of generating returns for their investors. They take capital, combine it with their belief in the superiority of their playbook, and then implement their strategies and playbooks in a given vertical. This may involve buying businesses or building tools to enhance their performance, generating profits, and returning the profits to their investors.
Until recently, you’d be forgiven for thinking PE and VC are effectively distinct entities. However, headlines like these are making it more apparent that they’re just a spectrum of strategies and that there’s a lot of white space in between them:
Why are VCs (and the companies they fund) adopting PE-like strategies? Let’s explore.
In seeking outsized returns, VCs and venture-funded startups are venturing beyond their previously narrowly defined model. They’re getting more creative and aggressive in exploring the messy middle, the whitespace between the previously distinct PE and VC ends of the spectrum.
Several factors are behind this move towards the messy middle. Some are pushes from the traditional VC model: the classic, almost boutique approach of minority investments in asset-light, high-growth, all-or-nothing, power-law-seeking, software-first-and-only startups. As this model gets more competitive, smart founders and investors realize they must try something different. At the same time, several powerful factors are pulling toward these new models: new technologies and business models seem to enable venture-like returns from traditionally non-venture-type businesses.
The push side is well-documented: the traditional VC asset class has become saturated, especially in B2B SaaS. Nearly a trillion dollars have flowed into the venture industry in the last decade. This has led to a proliferation of companies serving every vertical and every niche. Some market maps are so crowded that you need a microscope to make out a single logo:
At the same time, AI promises to further reduce the cost of software development. That isn’t to say that the B2B SaaS market is going to zero, or that there won’t be another generational B2B SaaS business. But the noise and saturation make it harder for these companies to grow quickly while retaining customers and high margins. There aren’t many land grab opportunities in pure SaaS like there were in the 2010s.
Even for companies with great products, it’s getting harder to sell to businesses with SaaS fatigue. To return to the original dental example: suppose you (the entrepreneurial dentist) build the best vertical software for dental practices. Your target customers are already inundated with such pitches. The same is true if you’re pitching the most well-oiled acquisition strategy for underperforming practices. It’s hard to sell them a genuinely better product, and it’s also hard to convince them to sell their businesses.
That brings us to the pull factors. What makes the non-pure-software approach so attractive? First, new tech and business models enable startups to monetize more than just software subscriptions. I talked about this in “Invisible asymptotes in vertical software”. Products like embedded payments with Rainforest* or embedded marketing with Reach* allow software companies to capture a variable portion of their customers’ success, upside that grows as their customers grow, and not just a fixed fee for software.
Another is the rise of AI as a credible substitute for certain types of work. This has two direct effects:
First, it allows significant costs to be taken out of a business and/or for labor to be added to places where it previously wasn’t economical. For example, an accounting firm that previously needed a large back office team for mundane, repetitive tasks can offload more of that to AI and reduce headcount. A small field services business can now use voice agents to answer the phone at a fraction of the cost of a full-time employee.
Second, AI allows companies to implement a broader, more consistent, and more scalable version of playbooks. If PE involves implementing playbooks for teams to follow, while VC involves building software that encodes playbooks into workflows and data models for teams to follow — both are vulnerable to human error. In both cases, the people involved need to actually follow and implement the playbooks. AI takes that out of human hands.
So, VC funds and venture-backed companies can and must explore strategies in the messy middle. They both (1) must move away from old and less effective models, and (2) can adopt new models with higher expected returns. That’s why seemingly unconventional company structures have emerged.
To improve businesses and generate returns, the VC model uses code as its primary source of leverage, while the PE model uses capital. The new models mix code and capital in unique ways to achieve the same result: improve how a set of businesses operates, then harvest upside. The latest mixtures of code and capital allow investors and entrepreneurs to work with more businesses. They also make it possible to create and capture more value than was previously possible in a pure VC or PE model.
The new models seem to fall into three categories: the crown jewel, the roll up, and business-in-a-box.
In the crown jewel model, a VC firm or VC-funded company acquires a one-off, large, strategic, and non-tech asset. The crown jewel might be a hospital or health system, a professional service firm in law or accounting, a call center or BPO, or a parking lot operator. The acquirer doesn’t simply acquire and run a business marginally better (as in traditional PE). The acquirer may already have a proprietary tech stack or strategy that it’s applying to the crown jewel asset. Or the acquirer may build such technology as it operates the new business, with the crown jewel asset as its ideal and captive first customer. Under this model, the acquirer applies proprietary tech to an already at-scale business where it will have the greatest and fastest ROI. Crown jewel examples include the AI-powered parking software company Metropolis acquiring a century-old, publicly-listed parking lot operator SP Plus for $1.5 billion, or General Catalyst acquiring a large healthcare system in Ohio for $500 million.
In a venture roll-up, a company acquires multiple non-tech assets and then applies its proprietary technology and strategies. Think of a roll-up in contrast with the opportunistic, often one-off, and strategic M&A of the crown jewel model. In the venture roll-up model, the M&A is continual and applied to multiple businesses. Traditional PE often involves a low-tech roll-up approach. The venture roll-up model differs from the PE roll-up because it involves applying a full stack of proprietary, purpose-built software for that vertical. The venture roll-up may also build in-house technology to assist and scale the M&A process, such as proprietary data and underwriting to identify, underwrite, and value the best acquisition targets. Examples include Cabana, Pipe Dream, and Long Lake in field services, as well as OLarry and Multiplier in professional services.
In the last model, business-in-a-box, the company actually helps create and start new businesses in a vertical. Like the roll-up model, it brings proprietary technology and works with multiple end businesses in parallel. But it creates these businesses rather than acquires them. It can create businesses under unique individual brands (business-in-a-box) or under a common brand (modern franchising). These can include purely digital services offered at least partly through a managed marketplace. Examples include Fora for travel agents or Headway for therapists, as well as brick-and-mortar businesses, such as Moxie for med spas. Sam Gerstenzang, the founder of Moxie and Boulton & Watt, is the expert on the model and wrote a great piece on which markets are most amenable to it.
These models are evolving quickly and aren’t mutually exclusive. For example, biz-in-a-box vendors may execute some opportunistic roll-ups or vice versa. Similarly, incumbent vertical software companies may begin adopting these new models. To return to the PG tweet above, if a vertical software provider finds its market or margins tapped by just selling software and services, it may be compelled to start operating businesses in their verticals. Alongside the list of products vertical SaaS companies offer, such as CRM and payments, it’s increasingly common to see an option to “Start your business with us” or even “Sell your business to us.” For example, Slice (“Start your pizzeria”) or MoeGo Care. This creates some interesting territory to navigate — including the potential for channel conflict and competing with existing customers.
The biggest companies are built and the best investments made when things are in flux, when generally accepted models have been exhausted, but no obvious replacement has risen. That flux is happening in VC and PE. The classic VC/PE investment model, as well as the traditional strategy of VC-backed, SaaS-centric, B2B software companies, is approaching a saturation point. It’s still early as funds and companies explore new combinations of code and capital, of software and financial engineering, in this messy middle. Interestingly, it isn’t just a game for new funds or companies. Some of the earliest examples of this trend are established investors (e.g., General Catalyst / Summa) and software companies (e.g., Metropolis / SP Plus). But the model is evolving, and there will be many new opportunities to build generational companies by creatively mixing code and capital.
My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: [email protected]
2025-03-26 22:30:51
Forget being dismissed as a ChatGPT wrapper. Anyone building vertical AI should fear being a wrapper around a system of record.
The loud debates over “AI versus software” frame the choices poorly. They obscure the right strategy for each player in the emerging stack: incumbent vertical software, emerging vertical AI, and general model companies. Let’s look at how that stack started and is evolving.
The classic software stack has three layers:
This architecture applies to single software products and companies' broader software stack. Businesses need reliable sources for important data like customers, expenses, and revenue. Employees generate this data in fragmented and sometimes conflicting ways. For example, information about a customer may be spread between the teams and tooling in sales, implementation, and billing—but it must ultimately be synthesized and reconciled into a single place.
The relative value of these layers has changed as software has evolved. In the early software age, only a handful of vendors existed. The winning ones developed all-in-one solutions and systems of record. They centered on vital business resources: employees (human capital management, HCM), customers (customer relationship management, CRM), and revenue/expenses (enterprise resource management, ERP). In this model, most of the value accrued to databases like Oracle, SAP, and Salesforce.
SaaS made software cheaper to create and distribute. This broke down interaction systems into many specialized apps. During this time, there were notable SOR IPOs like Workday, ServiceNow, and Veeva. However, SOE companies like Docusign, Box, Zoom, Slack, and Smartsheet really defined the era. They created value by digitizing and streamlining employee workflows.
The latest evolution of this stack is vertical software (vSaaS). It combines the SOI and SOR into one product designed for a specific vertical. For example, Clio for lawyers, Housecallpro for field services, Brightwheel for schools.
A single product in a vSaaS bundle is likely weaker than a general option. For example, Clio’s CRM isn’t as strong as Salesforce’s. However, lawyers still prefer Clio because it’s purpose-built for them and integrates with all the other modules that Clio provides. For example, a prospect in Clio’s CRM can be turned into a client, so lawyers on Clio can track time, assign work, bill hours, and get paid.
Vertical AI is shaking up the stack again. It comes in many flavors. Co-pilots augment labor and workflows. Agents offer a more invisible “do it for me” value proposition. AI is also making software easier and cheaper to build.
Intelligence is becoming cheaper. The software for interacting with it is also more affordable. Everyone thinks this means every business will build their own software. Or that they won’t need to build software per se because the intelligence at the interaction layer will be nearly free.
What becomes more valuable if intelligence is cheaper and the interactions with it are cheaper? It’s the data model for a vertical, the data for a specific business that fits its vertical data model, and the workflows and controls necessary to use that data to fit that specific business or industry. Or—put another way—a system of record.
Let’s take a hypothetical example in the roofing market. “ShingleSoft” is a vSaaS for roofing companies. It has a full suite of software products: CRM, estimates, scheduling, project management, inventory management, time tracking, payroll, billing and payments, accounting, etc.
“RoofGPT” is an AI-focused startup. It knows that many roofing companies can't hire full-time sales, marketing, and operations employees. Many sales calls to roofers go to voicemail while the employees are up on roofs. So RoofGPT offers a voice agent. It picks up on the first ring and qualifies customers. It’s the equivalent of having infinite smart and polite salespeople ready near a phone 24/7.
The problem is that these “salespeople,” no matter how smart or skilled, are disconnected from the business. They’re perfectly capable of requesting numbers for a callback, and answering deterministic questions about operating hours. But they struggle when they’re asked about something that an employee sitting in the roofer’s office would know.
“Can I reschedule my inspection?” requires access to the roofer’s CRM to look up the customer record and the employee schedule.
“Can I pay my bill over the phone and can you send me a receipt?” also requires access to the CRM, invoicing, and payments system.
If all the roofing companies use a fragmented suite of tools (e.g., CRM from Hubspot, scheduling from Calendly), RoofGPT could build API integrations with all of them. However, for many verticals, these functions have been consolidated into a single vSaaS, like ShingleSoft. This is a double-edged sword for RoofGPT. They can interact with a single platform to create and update records across multiple functions. But they’re also beholden to that single vendor. Suppose they choose not to integrate. Suppose they focus on providing excellent voice functionality without direct access to the SOR. In that case, they’ll face commoditizing pressure from increasingly capable horizontal AI tools (e.g., OpenAI’s Operator).
So RoofGPT is facing two pressures. First, the pressure of increasingly capable and commoditized intelligence. Second, the pressure of increasingly centralized, rare, and controlled data and interaction with the vSaaS providers.
ShingleSoft isn’t an AI-native company, so they may be slower to build AI features. They may already have a robust API and partner ecosystem, so they may support RoofGPT initially. However, the core strategy of vSaaS is clear: bundle, bundle, bundle. The more products they offer, the more roofers they can acquire and the more they can charge. As outlined in “Invisible asymptotes in vertical software”, successful vSaaS know they need to (1) solve as many problems as possible and (2) find monetization models beyond SaaS that both drive growth/success of their customers and capture more of that upside and growth.
“Pretty good” products that are deeply embedded into the core vSaaS product are likely to beat “Excellent” products that lack deep integration and lack platform distribution.
Put another way, if I’m a roofer, which of these options would I prefer?
(A) the world’s best salesperson, but they’re stuck in a room alone with no access to live info about my business
(B) a decent salesperson who is deeply familiar with business, services, schedule, and employees
Most would probably choose (B). That’s especially true if the gap between the quality of the salespeoples’ standalone skills keeps shrinking every month.
Every business is a wrapper. To be flippant, SaaS companies just wrap cloud providers, which wrap cloud hardware providers, which wrap semiconductor foundries. Being a wrapper is not in itself a bad thing. What you wrap and how you wrap it makes it bad or good.
Especially if you’re wrapping a commodity, you must give customers a reason to buy from you versus going direct. You can do this with product (by improving or adding value to it). You can also do it with distribution (selling it cheaper and/or more effectively than customers could get it themselves). Having one is good, having both is better.1
Today vertical AI agents are primarily wrapping product, building something novel enough that it’s getting them powerful distribution. However, there’s a limit to how much value they can add without owning or accessing the SOR. At the same time, “good enough” intelligence is being commoditized. I doubt intelligence will ever be so commoditized that the end B2B user relies exclusively on agents. But I think it will be sufficiently commoditized enough to seep into adjacent software products. It’s already happening. Successful vSaaS companies are expert bundlers. They’ve mastered multi-product motion. They also have existing distribution through their install base. And because they are the SOR, they can build an integrated experience much better.
So what’s the right strategy here? Will vAI or vSaaS win?
Emerging vAI companies have a harder path to success than they thought. Early fast growth will taper off as they, their customers, and vSaaS partners realize the value of integrating with the SOR (and limits of not being integrated with it). vAI companies should ignore the FUD around the “end of software” and have a clear plan to displace the SOR. This may apply less to vAI companies in verticals without a modern vSaaS incumbent. They’ll have an easier time starting with an AI wedge and building out the SOR rather than displacing another one.
Existing vSaaS companies are net beneficiaries of AI commoditization. It’s likely a sustaining rather than disruptive innovation to them. They have more time to make strategic moves in offering their customers AI products, whether by building, buying, or partnering.
Embedded AI for vSaaS is a newer category, empowering vSaaS to add vAI features faster and more successfully. This is different than simply embedding AI. It involves configuring AI to help vertical-specific workflows, such as marketing and customer support (e.g., Reach). Think how companies like Rainforest or Stripe enable vSaaS to embed payments rather than become payfacs themselves.
The dynamic between vAI and vSaaS is reminiscent of the early days of the streaming wars. There was competition between Netflix (a streaming platform that licensed content) and HBO (a content company without a streaming platform). In 2013, a Netflix exec famously said, "The goal is to become HBO faster than HBO can become us." The right answer wasn’t streaming or content but both together.
It’s worth noting that most of the major streaming services today are “full stack.” They own the content production and tech. They’re about evenly split. Around half started with streaming and got into content production (Netflix, Amazon Prime Video, Hulu, Apple TV). The other half started as content producers and got into streaming (HBO, Disney, Paramount, Peacock). I expect something similar will play out in B2B software, where the winners in vSaaS will own the IP (customer data and workflows), not to mention existing brand and distribution, and layer on the new tech.
The dichotomy of AI versus software is a false one, especially in B2B verticals. They complement each other, and each vertical’s winner will thoughtfully combine both.
My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: [email protected]
Think of cloud storage, something rare that turned into a commodity. Dropbox started off making this rare/difficult-to-use resource usable to the average person. It’s still a great company today, but as storage became commoditized, the winners in B2B/B2C are the ones that had an existing distribution advantage because of existing customer relationships and/or had products that enhanced the use/value of commodity storage (Apple’s Photos, Google’s Gmail and Photos and Drive).
2025-01-07 22:15:52
Several years ago I backpacked from Berlin to Beijing, covering much of the distance in a third-class car on the Trans-Siberian Railway through Russia and Mongolia. One night I was shaken awake at 3 am on the Mongolian-Chinese border by what felt like a derailment. I jumped out of bed and stared bleary-eyed out the window as railway workers detached each carriage from its wheel assembly and swapped it for one that fit the Chinese railway gauge.
Many countries have different tracks, either by design or historical accident, so many trains require different wheel assemblies to cross borders. Most passengers later woke up in the same carriage they fell asleep in, now traveling through a different country on different rails and wheels.
I thought of that Mongolian railyard often as I started learning about stablecoins1. Before that trip, I thought rail cars and their wheels were all the same, all purpose-built for the tracks they ride on, which are more or less the same globally. But that’s not true. Carriages, wheels, and tracks are separate but related elements, are designed and built with various priorities2, and are different worldwide.
The same is true of money and the financial infrastructure it’s built on. Neither is valuable without the other, so each is designed symbiotically, resulting in benefits and trade-offs.
Fiat currencies like US Dollars (USD) and Euros (EUR) are issued and managed by central banks and governments, who also help create and regulate their underlying rails. This centralization makes these currencies stable and useful, but it also restricts how the rails can be used and who can use them. Think of fiat currencies as safe, comfortable, and highly desirable railway cars that ride on rails that can be slow, opaque, and inaccessible to many. There are some differences between the rail systems of different countries, but they’re generally interoperable if you have enough time and money.
The blockchain and associated decentralized infrastructure gave rise to thousands of cryptocurrencies. While the infra was fast, global, permissionless, and transparent, the currencies themselves were often too volatile to pass the major tests of money. There’s plenty of value and utility in various cryptocurrencies. Still, none of them could be used as a day-to-day transactional currency – like there’s value and utility in assets like gold, but you still wouldn’t use it for transactions daily.
If fiat currency is an old-school railway system, blockchain is a magnetic levitation (meglev) train. It was open source, permissionless, and globally available, so anyone could build their own tracks and cars. This led to many valuable and interesting new vehicles and lines. Still, few wanted to ride them regularly or on long journeys since they weren’t comfortable, reliable, or safe at first.
Because this maglev system was so new, sometimes dangerous, and certainly long-term competitive, the older rail systems made interoperability difficult. They didn’t want maglev trains riding their rails.
But it was easy enough to retrofit the older but safer and more comfortable carriages to the fast, futuristic, and global rails. That’s effectively what stablecoins are: the best of both worlds. They are reliable cars that can ride on traditional or futuristic rails, switching easily between the two and connecting different rail systems.
Stablecoins have several valuable use cases between and within different financial systems.
The first is as a bridge between the fiat and crypto worlds. In this case, the value was more in the currency itself (and its stability) than in the infra. Stablecoins allow crypto users to store and exchange a stable form of value on chain3. Access to a global, nearly permissionless form of stable digital currency also helped people in countries without a stable local currency.
The second emerging use case is parallel infra within a fiat system or between different fiat systems. In this case, the value is in the stablecoin infra as much if not more than the currency itself. Because stablecoins are fast, cheap, global, and programmable, they’re promising complements or substitutes to traditional money movement products like cross-border payments, treasury management, and settlement. In this use case, the end users might not even know they’re using stablecoins, but they’re attracted to product benefits like speed and cost.
The third emerging use case is in building de novo stablecoin products that exist within the fiat world, where the value is in both stablecoins themselves and their infra. The idea is to offer the benefit of stability without the downsides of centralization. With fewer intermediaries and more transparency, money can move faster, cheaper, and more securely. This is still evolving, but interesting applications are appearing, such as stablecoin-only banks.
The most common type of stablecoin is fiat-collateralized: one stablecoin represents and can be redeemed for one unit of fiat currency – i.e., 1 stablecoin (USDT, USDC) = 1 USD. Other variations include asset-collateralized (e.g., gold), crypto-collateralized, and algorithmic stablecoins. We’ll focus on fiat-collateralized since it’s the most common and straightforward to understand.
Stablecoins are created by issuers, who create (“mint”) or destroy (“burn”) stablecoins in exchange for fiat, and partner with others to facilitate this exchange, increasing the use and indirectly the value of their stablecoin. Issuers monetize the float on these deposits.
Issuers mint stablecoins onto various blockchains, third-party (e.g., Ethereum) or first-party (e.g., Ripple). Different blockchains offer different features and benefits, such as increased throughput or security, and many stablecoins are compatible with multiple blockchains.
For example, say Alice wants to buy $100 of USDC. She sends $100 USD to Circle, which stores the fiat in their trust account at a bank. Circle then mints 100 USDC coins on the blockchain and sends them to Alice’s on-chain wallet.
Alice can send the USDC from her Circle wallet to Bob, who sends it to Carol. These are all nearly free and instant transfers since all three make transfers on the blockchain. However, each person treats the 100 USDC as if they were $100 USD, since they effectively are a claim on the $100 USD stored with the issuer. Let’s say Carol needs to convert her 100 USDC to USD: she sends it back to the issuer, who destroys the stablecoins and releases the equivalent in fiat to Carol.
It’s inefficient for end users to interact with issuers for every transaction, so they’ll partner explicitly or rely implicitly on liquidity providers, such as exchanges, OTC desks, financial institutions, or other market makers. These maintain pools of fiat and cryptocurrencies, often exchanging them for a spread on each transaction. This can be as simple as buying small amounts of USDC with fiat from Coinbase rather than from Circle, or more complex, like cross-border use cases where stablecoins are exchanged for an exotic local fiat.
Some stablecoin use cases, such as payments and remittances, are more complex. For example, say a company wanted to allow its users to send USD to various Latin American countries. It would need to support on- and off-ramps in different countries, maintain various first- and last-mile fiat infra, do KYC on senders and recipients, and manage liquidity pools for several currencies. It could also work with orchestrators, like Bridge, which handle the complexities of these funds flows and regulatory requirements.
Other players are beginning to emerge, such as businesses that look like more traditional merchant gateways, but for crypto (e.g., Transak, MoonPay), as well as stablecoin-native applications, such as Zarpay and Dakota.
The multi-billion dollar question is: Where does value accrue in the rapidly evolving stablecoin stack? The lines between these categories are already blurred. Some applications are building their own orchestration (e.g., Sling Money) and some liquidity providers are deeply partnering on issuance (e.g. Coinbase, Circle). The lines between these stablecoin layers are also blurring with the fiat world, whether it’s through building (Visa’s Tokenized Asset Platform), buying (Stripe + Bridge), or partnering (OKX and Singapore’s DBS). Although the end state of stablecoins is uncertain, the journey will be exciting!
As a reminder, I’m a partner at Matrix, an early-stage VC firm that invests in fintech and areas like AI, B2B, infrastructure, healthcare, and frontier tech. I focus on fintech and vertical software and am particularly interested in stablecoins. If you’re building or interested in the space, I’d love to hear from you: mb at matrix.vc
The modern financial and railway industries co-evolved in the last two centuries and borrowed many terms and analogies from each other, such as payment rails, wire transfers, and even interchange.
For example, Russia’s wider railway gauge was designed to withstand heavier loads, more extreme weather, and rougher terrain and make invasion by foreign armies more difficult, but it’s more expensive and limits interoperability.
This reflects a common pattern in technology described by Carlotta Perez’s book "Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages" (2002). Perez describes recurring cycles of "installation" and "deployment". During the installation phase, speculative financial capital drives the spread of new technologies, often leading to bubbles, which later burst. The deployment phase sees productive investment harnessing the technology for broader economic and societal benefits. So it wouldn’t be a stretch to say the greatest threat to SWIFT and Visa ultimately came from Bored Apes and Dogecoin, albeit indirectly.
2024-11-21 22:50:02
This is the fourth installment of the “X in 1,000 words” series, following interchange, payfacs, and real-time payments. These are intended to introduce critical but mis- or under-understood topics to people working or interested in fintech. It’s not an exhaustive guide, but the gentle introduction and overview I wish I had earlier. Questions and feedback are always welcome. You can learn more about and contact me here.
"Cross-border payments" are payments made between parties in different countries. While the concept is straightforward, the systems that move >$45 trillion annually across borders are anything but. That’s because cross-border payments (XBP) must account for things domestic payments take for granted.
Say I want to send $100 USD to a friend in Japan. Those funds need to somehow move between two banks that may not have a direct relationship with one another across different payment rails and regulatory regimes and eventually land as Japanese Yen (JPY) in an account around the world.
The various solutions to this involve two common parts: (1) acquiring and supporting local users on both ends of the transaction, including first/last mile of money movement and local regulatory compliance, and (2) the “middle mile” of moving money or value across borders, converting currencies, and managing FX and liquidity risks:
This note covers four XBP methods: correspondent banking, money transmission, payment aggregation, and stablecoins. I’ll discuss the trade-offs inherent in each solution, as well as the factors that affect the product and business strategies of XBP companies.
Correspondent banking is a long-standing and still dominant XBP method. It describes how banks establish arrangements and accounts with banks in other countries and then work together to provide services like XBP. For example, an American bank like Chase will maintain an account in a Japanese bank like SMBC funded with JPY.1 Banks use SWIFT to coordinate payments. SWIFT isn’t a payment rail but a secure messaging system. The money movement is accomplished by netting the local accounts and/or with settlement systems like CHIPS (US) or TARGET2 (Europe).
Say I wanted to send $100 to that Japanese friend. If Chase and SMBC have an existing relationship, they’d coordinate using SWIFT, net the JPY from Chase’s account at SMBC, and credit it to the recipient’s JPY account:
If the sender and recipient’s banks don’t have a pre-existing relationship, they’d use correspondent banks as intermediaries. In this case, Correspondent Bank A has the JPY nostro account with Correspondent Bank B:
Correspondent banking can involve multiple intermediaries, including in third countries, to complete transfers:
The benefit of this method is wide coverage: the network can eventually connect almost any two banks. However, this comes at the expense of speed and cost, as each intermediary takes time and a fee to process the funds through the network.
Money transmitters (MTs) such as Western Union and Moneygram are another long-standing and popular XBP method. They’re popular among the un/underbanked since the sender and/or receiver can transact in cash. MTs operate a global network of agents – physical storefronts such as conscience stores or currency exchange stalls – that offer MT services. Senders deposit cash with an agent and leave instructions for who can retrieve it elsewhere on the MT’s network.
For example, say I deposit $100 at a Western Union location in San Francisco and list my Japanese friend as the recipient. The agent verifies my request and then sends the funds to Western Union.
Western Union credits them to my friend in Japan and nets the funds between its USD and JPY accounts minus a fee. My friend can then pick up the equivalent in JPY at a Japanese Western Union agent by showing their ID or a confirmation code:
Correspondent banking and money transmitters are often critiqued for being slow and expensive. This cost and slowness are the downsides of their broad geographic coverage, resulting from their reliance on intermediaries. Because many MT users lack formal banking, an agent network is necessary for first/last mile distribution. In contrast, the lack of 1:1 global banking connectivity necessitates the correspondent banking network for the middle mile. Now let’s discuss two newer XBP models, which use technology to minimize intermediaries.
Payment aggregators like Wise can be considered digital-first money transmitters, with apps instead of agent networks. These companies maintain bank accounts in the countries they support, pre-funded with local currency, and the infrastructure to pay in from and out to local users on each end. The actual “cross border” transactions are often internal net transfers, similar to correspondent banking, but the fintech orchestrates the transaction.
Let’s return to the example above, but use Wise to send money to Japan. Initiating the transfer, I’ll send $100 from my bank account to Wise’s USD account:
Wise will then transfer the equivalent amount from its JPY account in Japan to my friend’s SMBC account. No USD leaves the US and no JPY enters Japan.
This is faster and cheaper than correspondent banking and money transmitters because there are fewer intermediaries. Because Wise is the intermediary, it has more control over everything from the UX to the costs. This benefit does not come easily though. Beyond maintaining the local accounts, Wise must acquire and support users, comply with local regulations like KYC, manage liquidity and FX risk across countries, and more. Wise users are also limited to countries where Wise has established on/off ramps.
The newest kid on the XBP block is the stablecoin, which offers several improvements on all other XBP methods. A stablecoin is a digital currency backed 1:1 by fiat currency like USD, so its value is constant, and it’s tradable instantly and globally. Since the blockchain and exchanges never close, stablecoins can be converted almost instantly to/from fiat. When combined with burgeoning 24/7 fiat real-time payment networks, stablecoins enable near-instant fiat > stablecoin > fiat transactions.
Taking the USD to JPY example again: once the sender initiates a transfer via Bridge or a platform that’s integrated it, USD moves over local fiat rails to Bridge’s local USD account:
Bridge then exchanges the USD for a stablecoin such as Tether (USDT), and transfers it to a wallet linked to its bank account in the recipient’s country. The USDT is then converted to JPY in Bridge’s local Japanese bank account and moved over local rails to the recipient’s account:
Like payment aggregators, stablecoin infra providers must maintain local accounts, follow local regulations and compliance, such as KYC/B senders and recipients, and more.
All XBP systems must solve the core problem that a sender and recipient, as well as their respective banks, may not be directly connected. The solutions to this problem create trade-offs in speed, cost, and coverage of supported countries/currencies.
Correspondent banking and money transmitters were pioneered in the pre-digital era2, so their models use networks of intermediaries in different ways to solve the same problem. They generally optimize for coverage at the expense of speed/cost. Payment aggregators and stablecoins use technology (e.g., better onboarding and servicing via mobile apps, faster/cheaper pay in/out via emerging RTP rails) to reduce or eliminate intermediaries:
Interestingly, some new players offer embedded models, either as a pure play (e.g., Airwallex, Nium, Bridge) or as a complement to their existing direct business (e.g., Wise Platform).
Beyond the mechanics of how money moves across borders, it’s important to understand how factors like sender/recipient and country/currency mix determine the strategy and economics of XBP companies.
The sender/recipient mix (C2C, B2C, C2B, B2B) determines distribution strategy, regulatory and compliance burden, product adjacencies, etc. Because businesses generally send and receive more payments more frequently than consumers, they have more pricing leverage and see lower take rates than mixes involving consumers. For example, Remitly (C2C) has a gross take rate of >200 bps versus Corpay (B2B)’s <60 bps.
The corridor is another important determinant of take rate. Generally corridors with larger volumes, more stable currencies, more balanced flows, modern banking infrastructures, and complementary regulatory regimes are more competitive and therefore have lower take rates. Inversely, there’s typically less competition and higher take rates with more volatile currencies, unbalanced and low/inconsistent flows, and antiquated financial infra. The take rate is up to 25x greater for the least competitive corridors.
Many XBP companies follow the general fintech trend of complementing low-margin transactional revenue with other complementary financial products and/or higher-margin software products. For example, Wise offers interest-bearing deposit accounts while Flywire offers vertical software for its key industries, like education and healthcare. Embedding for distribution is another popular strategy, with companies that were initially direct-to-consumer offering products like Wise’s Platform and Airwallex’s embedded solution.
That’s XBP in ~1,000 words! If you’re building in this space, email me: mb at matrix.vc
